On Tue, Jan 30, 2024 at 4:35 AM Alexandre Oliva <ol...@adacore.com> wrote: > > 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
OK > -- > 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
