Hi!
On 2025-01-10T11:35:49+0100, I wrote:
> On 2023-12-06T19:12:25-0300, Alexandre Oliva <ol...@adacore.com> wrote:
>> On Dec 6, 2023, Thomas Schwinge <tho...@codesourcery.com> 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:
<https://inbox.sourceware.org/dc805c2c-bd2b-4083-951d-278b96312...@codesourcery.com>
"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 <tschwi...@baylibre.com>
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
