[Bug middle-end/113100] [14 regression] many strub tests fail after r14-6737-g4e0a467302fea5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113100 --- Comment #5 from GCC Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:320fb976e933e8892af905e68de65492568f2a49 commit r14-8642-g320fb976e933e8892af905e68de65492568f2a49 Author: Alexandre Oliva Date: Wed Jan 31 00:13:36 2024 -0300 0From: Alexandre Oliva 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.
[Bug middle-end/113100] [14 regression] many strub tests fail after r14-6737-g4e0a467302fea5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113100 Kewen Lin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Kewen Lin --- Should be fixed on trunk.
[Bug middle-end/113100] [14 regression] many strub tests fail after r14-6737-g4e0a467302fea5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113100 --- Comment #3 from GCC Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:cb62101787555b7b32607b431fdfe6fcc8f3830f commit r14-7089-gcb62101787555b7b32607b431fdfe6fcc8f3830f Author: Kewen Lin 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113100 Kewen Lin 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113100 Kewen Lin 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 --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113100 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0
[Bug middle-end/113100] [14 regression] many strub tests fail after r14-6737-g4e0a467302fea5
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 Date: Thu Dec 14 04:50:45 2023 -0300 strub: sparc64: unbias the stack address [PR112917]
