Hello, PPC EABI targets are currently configured with both BIGGEST_ALIGNMENT and PREFERRED_STACK_BOUNDARY set to 128, I believe to accomodate
"a long double member within a structure or union shall start at the lowest available offset aligned on a 16byte boundary" Besides, for 32bit non-altivec targets, we have 64 for STACK_BOUNDARY. There is code in expand_main_function to force the stack pointer alignment to PREFERRED_STACK_BOUNDARY in such situations, not triggered for C like languages on those targets because FORCE_PREFERRED_STACK_BOUNDARY_IN_MAIN is not defined (maybe it should, btw). We apply this dynamic re-alignment to every subprogram with foreign convention in Ada, still, because alignment requests must always be obeyed when not to be rejected. It turns out that the current re-alignment code doesn't work for PPC. It first 'rounds' the stack pointer in place, and then resorts to allocate_dynamic_stack_space to "pick up the pieces", as the comment says. The latter triggers the 'allocate_stack' expander, which copies the back chain from the current stack pointer, which in turn retrieves garbage when the initial 'rounding' has had a real effect. One way of addressing that would be to adjust the re-alignment code so that it does not touch the stack pointer before calling allocate_dynamic_stack_space. Now, I'm a bit unclear on the meaning of the ABI statement quoted above, and on the real implications this should have in the compiler. Does it imply that a long double field *address* should always be a multiple of 16, or just that the *offset* should be such a multiple ? In the latter case, are bumping BIGGEST_ALIGNMENT and PREFERRED_STACK_BOUNDARY the only options ? Other thoughts ? Thanks in advance, Olivier
