nvptx: Add '__builtin_stack_address()' test case (was: Causes to nvptx bootstrap fail: [PATCH v5] Introduce strub: machine-independent stack scrubbing)
Checks
| Context |
Check |
Description |
| linaro-tcwg-bot/tcwg_gcc_build--master-arm |
success
|
Build passed
|
Commit Message
Hi!
On 2023-12-06T19:12:25-0300, Alexandre Oliva <oliva@adacore.com> wrote:
> On Dec 6, 2023, Thomas Schwinge <thomas@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, but
'__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", see attached.
Grüße
Thomas
From 91dec10f8b7502bdd333d75ab7a9e23a58c3f32d Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <tschwinge@baylibre.com>
Date: Fri, 13 Dec 2024 11:40:01 +0100
Subject: [PATCH] nvptx: Add '__builtin_stack_address()' test case
Documenting the status quo.
gcc/testsuite/
* gcc.target/nvptx/__builtin_stack_address-1.c: New.
---
.../nvptx/__builtin_stack_address-1.c | 36 +++++++++++++++++++
1 file changed, 36 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/nvptx/__builtin_stack_address-1.c
new file mode 100644
@@ -0,0 +1,36 @@
+/* Document what we do for '__builtin_stack_address()'. */
+
+/* { 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_stack_address();
+ sink(p);
+}
+/*
+** f:
+** \.visible \.func f
+** {
+** {
+** \.param\.u64 %out_arg1;
+** st\.param\.u64 \[%out_arg1\], %stack;
+** call sink, \(%out_arg1\);
+** }
+** ret;
+*/
+
+/* The concept of a '%stack' 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 {%stack} { xfail *-*-* } } } */
+
+/* As this is an internal-use built-in function, we don't bother with
+ emitting proper error diagnostics. */
--
2.34.1