https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468
--- Comment #30 from Dominik Vogt <vogt at linux dot vnet.ibm.com> --- (In reply to Eric Botcazou from comment #24) > The root cause of this mess is actually init_emit: > > REGNO_POINTER_ALIGN (VIRTUAL_INCOMING_ARGS_REGNUM) = STACK_BOUNDARY; > REGNO_POINTER_ALIGN (VIRTUAL_STACK_VARS_REGNUM) = STACK_BOUNDARY; > REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNAMIC_REGNUM) = STACK_BOUNDARY; > REGNO_POINTER_ALIGN (VIRTUAL_OUTGOING_ARGS_REGNUM) = STACK_BOUNDARY; > > 3 out of 4 are wrong for 32-bit SPARC. VIRTUAL_STACK_DYNAMIC_REGNUM is > fixable but not VIRTUAL_INCOMING_ARGS_REGNUM & VIRTUAL_OUTGOING_ARGS_REGNUM, > whose offset is defined by the ABI. So there's a fundamental mismatch between the middleend's stack layout and target ABIs (Sparc, maybe others)? Looks like this never showed up because the values are not used anyway. Grepping through the sources and a regression test with bogus values (255) instead of STACK_BOUNDARY shows no uses of the other three, and only the one use of REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNAMIC_REGNUM) in explow.c. > The code in init_emit looks wrong to me, as STACK_BOUNDARY is documented as: > > -- 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'. > > but it goes back to 1995; I guess nobody cared about it until Dominik's > patch. There are more potentially questionable uses of STACK_BOUNDARY that may not match its documentation. Hard to tell without analysing the individual uses in detail. So, this should be fixable by a simple target macro VIRTUAL_STACK_DYNAMIC_ALIGN or something like that (not adressing the INCOMING/OUTGOING_ARGS alignment thing.)
