On Jan 19, 2024, Alexandre Oliva <ol...@adacore.com> wrote: > On Jan 18, 2024, "Kewen.Lin" <li...@linux.ibm.com> wrote: >> Not sure if I missed something in the testing, could you >> kindly double check if those test cases started to fail from r14-6275 on your >> env?
> My guess is that they started to fail when David attempted to bypass the > strub tests by changing the dg proc that detects strub support. The > tests then detected the mismatch between the result of the proc and the > expected errors when strub is disabled properly. The patch below, that realigns stack scrubbing on sparc32 and sparc64, is still pending review (Ping?), but since your fix for ppc (that worsened scrubbing on sparc32) has long been in, I'm pushing the reversal of commit 9773ca519864e2e0706424b805c3314f1fbe7d10. > 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.in: Rebuilt. Ping? https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643408.html -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
