[Bug middle-end/113100] New: [14 regression] many strub tests fail after r14-6737-g4e0a467302fea5

[Bug middle-end/113100] New: [14 regression] many strub tests fail after r14-6737-g4e0a467302fea5

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113100

            Bug ID: 113100
           Summary: [14 regression] many strub tests fail after
                    r14-6737-g4e0a467302fea5
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:4e0a467302fea56d63b7a6d17f99c0f388960dc7, r14-6737-g4e0a467302fea5

FAIL: c-c++-common/strub-defer-O1.c  -std=gnu++14 execution test
FAIL: c-c++-common/strub-defer-O1.c  -std=gnu++17 execution test
FAIL: c-c++-common/strub-defer-O1.c  -std=gnu++20 execution test
FAIL: c-c++-common/strub-defer-O1.c  -std=gnu++98 execution test
FAIL: c-c++-common/strub-defer-O2.c  -std=gnu++14 execution test
FAIL: c-c++-common/strub-defer-O2.c  -std=gnu++17 execution test
FAIL: c-c++-common/strub-defer-O2.c  -std=gnu++20 execution test
FAIL: c-c++-common/strub-defer-O2.c  -std=gnu++98 execution test
FAIL: c-c++-common/strub-defer-Os.c  -std=gnu++14 execution test
FAIL: c-c++-common/strub-defer-Os.c  -std=gnu++17 execution test
FAIL: c-c++-common/strub-defer-Os.c  -std=gnu++20 execution test
FAIL: c-c++-common/strub-defer-Os.c  -std=gnu++98 execution test
FAIL: c-c++-common/torture/strub-run1.c   -O0  execution test
FAIL: c-c++-common/torture/strub-run1.c   -O1  execution test
FAIL: c-c++-common/torture/strub-run1.c   -O2  execution test
FAIL: c-c++-common/torture/strub-run1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: c-c++-common/torture/strub-run1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: c-c++-common/torture/strub-run1.c   -Os  execution test
FAIL: c-c++-common/torture/strub-run2.c   -O0  execution test
FAIL: c-c++-common/torture/strub-run2.c   -O1  execution test
FAIL: c-c++-common/torture/strub-run2.c   -O2  execution test
FAIL: c-c++-common/torture/strub-run2.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: c-c++-common/torture/strub-run2.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: c-c++-common/torture/strub-run2.c   -Os  execution test
FAIL: c-c++-common/torture/strub-run3.c   -O0  execution test
FAIL: c-c++-common/torture/strub-run3.c   -O1  execution test
FAIL: c-c++-common/torture/strub-run3.c   -O2  execution test
FAIL: c-c++-common/torture/strub-run3.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: c-c++-common/torture/strub-run3.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: c-c++-common/torture/strub-run3.c   -Os  execution test
FAIL: c-c++-common/torture/strub-run4.c   -O0  execution test
FAIL: c-c++-common/torture/strub-run4.c   -O1  execution test
FAIL: c-c++-common/torture/strub-run4.c   -O2  execution test
FAIL: c-c++-common/torture/strub-run4.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: c-c++-common/torture/strub-run4.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: c-c++-common/torture/strub-run4.c   -Os  execution test
FAIL: c-c++-common/torture/strub-run4c.c   -O0  execution test
FAIL: c-c++-common/torture/strub-run4c.c   -O1  execution test
FAIL: c-c++-common/torture/strub-run4c.c   -O2  execution test
FAIL: c-c++-common/torture/strub-run4c.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: c-c++-common/torture/strub-run4c.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: c-c++-common/torture/strub-run4c.c   -Os  execution test
FAIL: c-c++-common/torture/strub-run4d.c   -O0  execution test
FAIL: c-c++-common/torture/strub-run4d.c   -O1  execution test
FAIL: c-c++-common/torture/strub-run4d.c   -O2  execution test
FAIL: c-c++-common/torture/strub-run4d.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: c-c++-common/torture/strub-run4d.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: c-c++-common/torture/strub-run4d.c   -Os  execution test
FAIL: c-c++-common/torture/strub-run4i.c   -O0  execution test
FAIL: c-c++-common/torture/strub-run4i.c   -O1  execution test
FAIL: c-c++-common/torture/strub-run4i.c   -O2  execution test
FAIL: c-c++-common/torture/strub-run4i.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: c-c++-common/torture/strub-run4i.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: c-c++-common/torture/strub-run4i.c   -Os  execution test
FAIL: g++.dg/strub-run1.C  -std=gnu++14 execution test
FAIL: g++.dg/strub-run1.C  -std=gnu++17 execution test
FAIL: g++.dg/strub-run1.C  -std=gnu++20 execution test
FAIL: g++.dg/strub-run1.C  -std=gnu++98 execution test

There is no output from any of the failures.  Running one in gdb I see:

(gdb) run
Starting program: /home/seurer/gcc/git/build/gcc-test/strub-defer-O1.exe 

Program received signal SIGSEGV, Segmentation fault.
0x00000000100006e4 in 00000019.plt_call.__strub_leave@@GCC_14.0.0 ()
(gdb) where
#0  0x00000000100006e4 in 00000019.plt_call.__strub_leave@@GCC_14.0.0 ()
#1  0x0000000010000c20 in main () at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/c-c++-common/strub-defer-O3.c:106

[Bug middle-end/113100] [14 regression] many strub tests fail after r14-6737-g4e0a467302fea5

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113100

seurer at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
               Host|                            |powerpc64le-linux-gnu
              Build|                            |powerpc64le-linux-gnu
             Target|                            |powerpc64le-linux-gnu
                 CC|                            |aoliva at gcc dot gnu.org

--- Comment #1 from seurer at gcc dot gnu.org ---
commit 4e0a467302fea56d63b7a6d17f99c0f388960dc7 (HEAD, refs/bisect/bad)
Author: Alexandre Oliva <oliva@adacore.com>
Date:   Thu Dec 14 04:50:45 2023 -0300

    strub: sparc64: unbias the stack address [PR112917]

[Bug middle-end/113100] [14 regression] many strub tests fail after r14-6737-g4e0a467302fea5

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113100

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0

[Bug middle-end/113100] [14 regression] many strub tests fail after r14-6737-g4e0a467302fea5

[linkw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113100

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |linkw at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-12-21

--- Comment #2 from Kewen Lin <linkw at gcc dot gnu.org> ---
Confirmed, but it needs an explicit cpu type like -mcpu=power9 for
reproduction, otherwise it could pass on power10 as it can work with pcrel (so
no toc base r2 needed). The change can extend the end of scrubbing, it cleans
the saved toc base unexpectedly.

I noticed that there is one macro SPARC_STACK_BOUNDARY_HACK, which aims to
indicate this SPARC64 specific behavior. Could we leverage this macro (guarded
the biasing with it)? like:

diff --git a/gcc/builtins.cc b/gcc/builtins.cc
index 125ea158ebf..9bad1e962b4 100644
--- a/gcc/builtins.cc
+++ b/gcc/builtins.cc
@@ -5450,6 +5450,7 @@ expand_builtin_stack_address ()
   rtx ret = convert_to_mode (ptr_mode, copy_to_reg (stack_pointer_rtx),
                              STACK_UNSIGNED);

+#ifdef SPARC_STACK_BOUNDARY_HACK
   /* Unbias the stack pointer, bringing it to the boundary between the
      stack area claimed by the active function calling this builtin,
      and stack ranges that could get clobbered if it called another
@@ -5476,7 +5477,9 @@ expand_builtin_stack_address ()
      (caller) function's active area as well, whereas those pushed or
      allocated temporarily for a call are regarded as part of the
      callee's stack range, rather than the caller's.  */
-  ret = plus_constant (ptr_mode, ret, STACK_POINTER_OFFSET);
+  if (SPARC_STACK_BOUNDARY_HACK)
+    ret = plus_constant (ptr_mode, ret, STACK_POINTER_OFFSET);
+#endif

   return force_reg (ptr_mode, ret);
 }

[Bug middle-end/113100] [14 regression] many strub tests fail after r14-6737-g4e0a467302fea5

[linkw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113100

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |linkw at gcc dot gnu.org
                URL|                            |https://gcc.gnu.org/piperma
                   |                            |il/gcc-patches/2024-January
                   |                            |/642090.html
             Status|NEW                         |ASSIGNED

[Bug middle-end/113100] [14 regression] many strub tests fail after r14-6737-g4e0a467302fea5

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113100

--- Comment #3 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:cb62101787555b7b32607b431fdfe6fcc8f3830f

commit r14-7089-gcb62101787555b7b32607b431fdfe6fcc8f3830f
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Tue Jan 9 23:05:13 2024 -0600

    strub: Only unbias stack point for SPARC_STACK_BOUNDARY_HACK [PR113100]

    As PR113100 shows, the unbiasing introduced by r14-6737 can
    cause the scrubbing to overrun and screw some critical data
    on stack like saved toc base consequently cause segfault.

    By checking PR112917, IMHO we should keep this unbiasing
    guarded under SPARC_STACK_BOUNDARY_HACK (TARGET_ARCH64 &&
    TARGET_STACK_BIAS), similar to some existing code special
    treating SPARC stack bias.

            PR middle-end/113100

    gcc/ChangeLog:

            * builtins.cc (expand_builtin_stack_address): Guard stack point
            adjustment with SPARC_STACK_BOUNDARY_HACK.

[Bug middle-end/113100] [14 regression] many strub tests fail after r14-6737-g4e0a467302fea5

[linkw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113100

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #4 from Kewen Lin <linkw at gcc dot gnu.org> ---
Should be fixed on trunk.

[Bug middle-end/113100] [14 regression] many strub tests fail after r14-6737-g4e0a467302fea5

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113100

--- Comment #5 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Alexandre Oliva <aoliva@gcc.gnu.org>:

https://gcc.gnu.org/g:320fb976e933e8892af905e68de65492568f2a49

commit r14-8642-g320fb976e933e8892af905e68de65492568f2a49
Author: Alexandre Oliva <oliva@adacore.com>
Date:   Wed Jan 31 00:13:36 2024 -0300

    0From: Alexandre Oliva <oliva@adacore.com>

    strub: introduce STACK_ADDRESS_OFFSET

    Since STACK_POINTER_OFFSET is not necessarily at the boundary between
    caller- and callee-owned stack, as desired by
    __builtin_stack_address(), and using it as if it were or not causes
    problems, introduce a new macro so that ports can define it suitably,
    without modifying STACK_POINTER_OFFSET.


    for  gcc/ChangeLog

            PR middle-end/112917
            PR middle-end/113100
            * builtins.cc (expand_builtin_stack_address): Use
            STACK_ADDRESS_OFFSET.
            * doc/extend.texi (__builtin_stack_address): Adjust.
            * config/sparc/sparc.h (STACK_ADDRESS_OFFSET): Define.
            * doc/tm.texi.in (STACK_ADDRESS_OFFSET): Document.
            * doc/tm.texi: Rebuilt.