nvptx: Add '__builtin_stack_address()' test case (was: Causes to nvptx bootstrap fail: [PATCH v5] Introduce strub: machine-independent stack scrubbing)

[Thomas Schwinge <tschwinge@baylibre.com>]

[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]

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



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-nvptx-Add-__builtin_stack_address-test-case.patch --]
[-- Type: text/x-diff, Size: 1745 bytes --]

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

diff --git a/gcc/testsuite/gcc.target/nvptx/__builtin_stack_address-1.c b/gcc/testsuite/gcc.target/nvptx/__builtin_stack_address-1.c
new file mode 100644
index 000000000000..5e976dc384bc
--- /dev/null
+++ b/gcc/testsuite/gcc.target/nvptx/__builtin_stack_address-1.c
@@ -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