https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #5 from Dominik Vogt <vogt at linux dot vnet.ibm.com> ---
Sounds fair. So, either the bug is that the stack pointer has 8 byte
alignment, or the formula for STACK_DYNAMIC_OFFSET results in the the wrong
amount:
-- rs6000.h --
/* Offset from the stack pointer register to an item dynamically
allocated on the stack, e.g., by `alloca'.
The default value for this macro is `STACK_POINTER_OFFSET' plus the
length of the outgoing arguments. The default is correct for most
machines. See `function.c' for details. */
#define STACK_DYNAMIC_OFFSET(FUNDECL) \
(RS6000_ALIGN (crtl->outgoing_args_size, \
(TARGET_ALTIVEC || TARGET_VSX) ? 16 : 8) \
+ (STACK_POINTER_OFFSET))
-- snip --
Or there is some place that doesn't properly use STACK_DYNAMIC_OFFSET().
--
Hm, if neither TARGET_ALTIVEC nor TARGET_VSX is set, we would get an 8 byte
aligned STACK_DYNAMIC_OFFSET while the STACK_BOUNDARY from aix.h is 128. The
common code uses STACK_BOUNDARY as the assumed alignment, which is wrong =>
bang.
I don't know about the AIX Abi, but there are (at least) three ways to fix
that:
1) Provide a version in STACK_DYNAMIC_OFFSET in aix.h that always rounds up to
STACK_BOUNDARY.
2) In aix.h, use 128 bit STACK_BOUNDARY only if TARGET_ALITVEC or TARGET_VSX is
set (probably breaks the Abi?).
3) Introduce another macro into common code to override the hard wired
REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNAMIC_REGNUM) = STACK_BOUNDARY. Use a new
macro that with the value "((TARGET_ALTIVEC || TARGET_VSX) ? 128 : 64)".
The latter is probably the most flexible solution, but I'm not sure if that's
really necessary.
