This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug bootstrap/77359] [7 Regression] AIX bootstrap failure due to alignment of stack pointer + STACK_DYNAMIC_OFFSET
- From: "vogt at linux dot vnet.ibm.com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 31 Aug 2016 13:01:48 +0000
- Subject: [Bug bootstrap/77359] [7 Regression] AIX bootstrap failure due to alignment of stack pointer + STACK_DYNAMIC_OFFSET
- Auto-submitted: auto-generated
- References: <bug-77359-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #6 from Dominik Vogt <vogt at linux dot vnet.ibm.com> ---
> Presumably something in the rs6000 backend is not maintaining or not
> instructing the common part of GCC to maintain the alignment on AIX,
> but presumably is maintained on Linux.
Might be a problem with Linux too:
-- rs6000.h --
#define STACK_BOUNDARY \
((TARGET_32BIT && !TARGET_ALTIVEC && !TARGET_ALTIVEC_ABI && !TARGET_VSX) \
? 64 : 128)
-- snip --
This may also result in a STACK_BOUNDARY of 128 and STACK_DYNAMIC_OFFSET being
rounded to a multiple of 8 bytes.
I don't quite understand the point in requiring STACK_DYNAMIC_OFFSET to be 16
byte aligned with altivec. If some memory (a vector?) needs to be aligned more
than 8 bytes in the dynamic area, you can just make the area larger but keep
the 8 byte alignment. Either way you'll have 8 unused bytes in front of the
vector to enforce alignment.
The real problem seems to be that common code just assumes that stack pointer
alignment is the same as alignment of the dynamic stack area.