[Bug middle-end/78468] [8 regression] libgomp.c/reduction-10.c and many more FAIL

[wilco at gcc dot gnu.org]

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

--- Comment #42 from Wilco <wilco at gcc dot gnu.org> ---
(In reply to Eric Botcazou from comment #41)
> > If you cannot guarantee the alignment of the pointers to STACK_BOUNDARY then
> > STACK_BOUNDARY is incorrect.
> 
> No, it is correct as per the definition:
> 
>  -- Macro: STACK_BOUNDARY
>      Define this macro to the minimum alignment enforced by hardware
>      for the stack pointer on this machine.  The definition is a C
>      expression for the desired alignment (measured in bits).  This
>      value is used as a default if `PREFERRED_STACK_BOUNDARY' is not
>      defined.  On most machines, this should be the same as
>      `PARM_BOUNDARY'.

Indeed, so that means alloca code can safely rely on SP being aligned to
STACK_BOUNDARY.

> > GCC uses the STACK_BOUNDARY guarantee in optimizations so it is essential to 
> > get this right if you want correct code  generation.
> 
> No, you're interpolating, please read the entire discussion.  Your change is
> based on a premise that is wrong at least on 32-bit SPARC.

Yes I did, and it is quite clear - if SPARC doesn't guarantee alignment of the
pointers, it setting of STACK_BOUNDARY is simply incorrect. Alloca will access
data below SP if SP is not aligned to STACK_BOUNDARY even before my patch. No
amount of extra padding to try hiding the bug will fix that.