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.
