EABI stack alignment for ppc

[Olivier Hainque <hainque at adacore dot com>]

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