Hello,
This patch does two things:
- deprecates the architecture variable EXTRA_STACK_ALIGNMENT_NEEDED
- flips that variables default so that it is initially disabled (architectures adjusted where needed)
The code in question (from hand_function_call) reads:
/* elz: on HPPA no need for this extra alignment, maybe it is needed
on other architectures. This is because all the alignment is
taken care of in the above code (ifdef REG_STRUCT_HAS_ADDR) and
in hppa_push_arguments */
if (EXTRA_STACK_ALIGNMENT_NEEDED)
{
/* MVS 11/22/96: I think at least some of this stack_align code
is really broken. Better to let PUSH_ARGUMENTS adjust the
stack in a target-defined manner. */
if (STACK_ALIGN_P () && INNER_THAN (1, 2))
{
/* If stack grows down, we must leave a hole at the top. */
int len = 0;
for (i = nargs - 1; i >= 0; i--)
len += TYPE_LENGTH (VALUE_ENCLOSING_TYPE (args[i]));
if (CALL_DUMMY_STACK_ADJUST_P)
len += CALL_DUMMY_STACK_ADJUST;
sp -= STACK_ALIGN (len) - len;
}
}
Several things to note:
- The alignment code is only enabled when EXTRA_STACK_ALIGNMENT_NEEDED and STACK_ALIGN_P(). While EXTRA_STACK_ALIGNMENT_NEEDED defaults to 1 (and few architectures clear it), it turns out that very few architectures provide a STACK_ALIGN method and consequently most architectures don't have the above code enabled. In fact, as best I can tell, the above is only used by the m68k, m68hc11 and SPARC. (I've attached a text file containing the relevant values).
- Unless there is some obscure magic going on (such as the TYPE_LENGTH always being aligned), the above, given an odd sized type, will most likely mis-align the SP and not align it! Scary!
Anyway, this patch deprecates the method, and I'll commit it in a day or so.
Andrew