From patchwork Fri Jan 10 10:53:04 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Thomas Schwinge X-Patchwork-Id: 104467 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 92B283858423 for ; Fri, 10 Jan 2025 10:54:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 92B283858423 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.a=rsa-sha256 header.s=20230601 header.b=Ni9lqrbI X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) by sourceware.org (Postfix) with ESMTPS id E98C93858D3C for ; Fri, 10 Jan 2025 10:53:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E98C93858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=baylibre.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E98C93858D3C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::331 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1736506389; cv=none; b=EykwCnlpvkYpmx/o3R9Q9L4g8BUqPCllumA/dCeRkKl5KVwj9BaCGJEF8CVtvr2IB5mrzfEO6YzvkJnoerTpEjs2jHYOE6V9kMRHygD3uCw9KMiUzgql0nMtPLKkgTm9v//FfnhWC2Hkmr3ghinahE1abNu9w20CaeL9JYSPia0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1736506389; c=relaxed/simple; bh=8GvwAjbzGVdb5xl6wKGw8GdVWdeGwAVE3SMER4R83mQ=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=CR8KtlQbb+7HyORb5IT4tjo4dqwKExqb/YolW5atjE8Jh/vcmJLfYAQZM4Wc0bJMwk2V8cEIvwcO2tlisDPE2W3KgvLh0kpplMfDh+vfpV2wViPhRAoxH6N8GHbtoMD+RlZKBewxeez9nqyEywgM9222yPdw6GhE4zeC2bWSMnM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E98C93858D3C Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-43675b1155bso22127125e9.2 for ; Fri, 10 Jan 2025 02:53:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1736506387; x=1737111187; darn=gcc.gnu.org; h=mime-version:message-id:date:user-agent:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=KfXLdmkDDFulDMUF+mwTYUy3cUJvgO+4jrgfM36M+6U=; b=Ni9lqrbIRS0M1dYO8HicYXYjbg6htaNzLNaeGUqCUE/UHWDE6h9m1c1hiOl3UlJk25 Ti+NfZbrlmhBJkCuTfxRMExdhUMicFN4who0NLSQoXSpJZaspFVEG0AF4bgvbSEeparH McnmfIO28oltfsc9m+nsgL3qOqBa6K9hh4JHx4iHeULfma5x9vJflEOVlgT4c7S0i+Sh ultWr0suH/Y1dJMpNbCDjLp8otPOftOqvyyBD7u39jyRW7sZ0PvcyDB08nNwxN4fFI4I aw93dL2ksbviesiix93NABp8O7mUz5HzJX7sI7u6YpFKc+kNxrHjG/WeQ+4C6U4MfOA+ aFbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736506387; x=1737111187; h=mime-version:message-id:date:user-agent:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=KfXLdmkDDFulDMUF+mwTYUy3cUJvgO+4jrgfM36M+6U=; b=kmaA73xKTQjVUkUm1zISsLKmhr2Fxky7Um/u4a+hc1j1M3kLvQiLOISzAplF2AEowk yLdBcydCMOwxBsL0eTPdBvAs4N5RJD4ducOEQqG9WaGj+OpIgXnE+SJWk7Ewk2lNtoGH 8uK8mLIrId4lc2+zX7g4d/Uge+WtqnoRbTmb0fpIAeqLbwHZ6yQNLp5YkrIS3mUNhFXt ge18HyC67C1GTtwqCIMWDSvGowYLZUkq/TxyM3RKSlvs1FzfCorlXWT9q4u8nM/RO1r4 9/jD5ugcbbJ1zTH2fT9SwqpyTXO+sV4b3+ugDrNwz/qzl416V1ly92rDVG1T24kZ53ZN zGzQ== X-Forwarded-Encrypted: i=1; AJvYcCXcMBLdUsAWxJ++oO5VwQ7nHS0uIhM9hsuc/OM9Pz/RKqn/+lxcpuSymO54zkKuCNtEPQonV0xRN6WlHw==@gcc.gnu.org X-Gm-Message-State: AOJu0YzHX1eV4GQMxSzZ7fh8hlTwXNQMJRJgjB9bZ3iq+sRdNSHJk/Io N5JrXyeJqeLjxxv2MwDQ4dkGC8mpFsoDi2iVZiTUpeFNVh5TfMbxx18mpTW9wY0= X-Gm-Gg: ASbGnct5R2iFygufnPhESG/XcyBO8CxAiNiAESIx2WLuTRaPocEEA14H5DboZunnB+E ac1+M41/e2zbUz6PuUwTtX1Ovn0eAr57OrR6xYpFOPOVnSe9osE8E2o8DjPkIzD0t0o43I2W0vI HyWRYoeT8NvBwMqUPeiPpegvLtaUpxX5fcFgX1MDoi2hQqaBkJx/2uA1kyPqfv3bRb1HP+a+3BB C7cq+zBSy6bf1wb9shJkB3szbPC7A0ip74w7RflDm60m5FQiutWqTe4pCPShZFXTgKLlD33ec/y TRmweCfG2mZnB4crVCIdZ7LpwH4btRzLzvlY7skH5TcJIUQEtLDfy2qGvIOsUn8= X-Google-Smtp-Source: AGHT+IFqzhj6SpABctUR6W8mYHyRREwA29sEWPfOEzDIw/c5Q/lp7GGMlDxaR/RDkm/y1BjuLLO9wA== X-Received: by 2002:a05:600c:1c8f:b0:434:f586:753c with SMTP id 5b1f17b1804b1-436e2686096mr95323485e9.7.1736506387544; Fri, 10 Jan 2025 02:53:07 -0800 (PST) Received: from euler.schwinge.ddns.net (p200300c8b743ca00d37840a5117bb56d.dip0.t-ipconnect.de. [2003:c8:b743:ca00:d378:40a5:117b:b56d]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-436e9e62333sm47650755e9.36.2025.01.10.02.53.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jan 2025 02:53:07 -0800 (PST) From: Thomas Schwinge To: Alexandre Oliva , gcc-patches@gcc.gnu.org Cc: Tom de Vries , Tobias Burnus Subject: nvptx: Add '__builtin_frame_address(0)' test case (was: nvptx: Add '__builtin_stack_address()' test case (was: Causes to nvptx bootstrap fail: [PATCH v5] Introduce strub: machine-independent stack scrubbing)) In-Reply-To: <87tta77y7u.fsf@euler.schwinge.ddns.net> References: <87lea7sh0h.fsf@euler.schwinge.homeip.net> <87tta77y7u.fsf@euler.schwinge.ddns.net> User-Agent: Notmuch/0.30+8~g47a4bad (https://notmuchmail.org) Emacs/29.4 (x86_64-pc-linux-gnu) Date: Fri, 10 Jan 2025 11:53:04 +0100 Message-ID: <87r05b7xf3.fsf@euler.schwinge.ddns.net> MIME-Version: 1.0 X-Spam-Status: No, score=-12.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces~patchwork=sourceware.org@gcc.gnu.org Hi! On 2025-01-10T11:35:49+0100, I wrote: > On 2023-12-06T19:12:25-0300, Alexandre Oliva wrote: >> On Dec 6, 2023, Thomas Schwinge wrote: >>> As I understand things, ["strub"] cannot be implemented (at the call site) for >>> nvptx, given that the callee's stack is not visible there: PTX is unusual >>> in that the concept of a "standard" stack isn't exposed. >> >> Not even when one PTX function calls another? Interesting. I'd hoped >> that with control over entering and leaving strub contexts, one could >> (manually) ensure they'd run in the same execution domain. But if not >> even that is possible, it will render the current strub implementation >> entirely unusable for this target indeed. >> >> Now, it doesn't seem to me that the build errors being experienced have >> to do with that, but rather with lack of or incomplete support for >> __builtin_{frame,stack}_address(). Are those errors expected when using >> these builtins on this target? I'd have expected them to compile, even >> if something went wrong at runtime. > > '__builtin_frame_address()' should be fine Actually, it isn't -- at least not always. As Tobias' original report: "Causes to nvptx bootstrap fail: [PATCH v5] Introduce strub: machine-independent stack scrubbing" implies, it here fails in the same way as: > '__builtin_stack_address()' synthesizes code that fails to assemble. > (Which is "OK".) To document the status quo, I've pushed to trunk branch > commit 91dec10f8b7502bdd333d75ab7a9e23a58c3f32d > "nvptx: Add '__builtin_stack_address()' test case" Pushed to trunk branch commit 86175a64f167e3b1701132fa1684d76230054c36 "nvptx: Add '__builtin_frame_address(0)' test case", see attached. Grüße Thomas From 86175a64f167e3b1701132fa1684d76230054c36 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 13 Dec 2024 11:40:01 +0100 Subject: [PATCH] nvptx: Add '__builtin_frame_address(0)' test case Documenting the status quo. gcc/testsuite/ * gcc.target/nvptx/__builtin_frame_address_0-1.c: New. --- .../nvptx/__builtin_frame_address_0-1.c | 36 +++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 gcc/testsuite/gcc.target/nvptx/__builtin_frame_address_0-1.c diff --git a/gcc/testsuite/gcc.target/nvptx/__builtin_frame_address_0-1.c b/gcc/testsuite/gcc.target/nvptx/__builtin_frame_address_0-1.c new file mode 100644 index 000000000000..35817769d31f --- /dev/null +++ b/gcc/testsuite/gcc.target/nvptx/__builtin_frame_address_0-1.c @@ -0,0 +1,36 @@ +/* Document what we do for '__builtin_frame_address(0)'. */ + +/* { dg-do compile } + TODO We can't 'assemble' this -- it's invalid PTX code. */ +/* { dg-options -O3 } */ +/* { dg-additional-options -save-temps } */ +/* { dg-final { check-function-bodies {** } {} } } */ + +void sink(void *); + +void f(void) +{ + void *p; + p = __builtin_frame_address(0); + sink(p); +} +/* +** f: +** \.visible \.func f +** { +** { +** \.param\.u64 %out_arg1; +** st\.param\.u64 \[%out_arg1\], %frame; +** call sink, \(%out_arg1\); +** } +** ret; +*/ + +/* The concept of a '%frame' pointer doesn't apply like this for + '-mno-soft-stack': PTX "native" stacks (TODO), and for '-msoft-stack' in + this form also constitutes invalid PTX code (TODO). + + { dg-final { scan-assembler-not {%frame} { xfail *-*-* } } } */ + +/* As this is an internal-use built-in function, we don't bother with + emitting proper error diagnostics. */ -- 2.34.1