http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527
Bug #: 50527 Summary: inconsistent vla align Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: vr...@gcc.gnu.org Created attachment 25367 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25367 testcase, modified from pr43513.c testcase To reproduce on x86_64: ... $ gcc -Os pr43513-align.c --param large-stack-frame=30 $ ./a.out 16byte aligned 7fff5c4ce00c ... The address of the vla is printed, and it's not 16-byte aligned (ends in 'c'). Nevertheless the test whether the address is 16-byte aligned succeeds, and the string '16byte aligned' is printed. During compilation the following scenario happens: - During the propagation of the first ccp phase, the align of the alloca (16) is progagated to the lhs results.0D.3306_13 as lattice value 'CONSTANT 0x00000000000000000 (0xfffffffffffffffffffffffffffffff0)'. - This not propagated through 'D.3307_14 = &*results.0D.3306_13'. The propagation does not look at the lattice value of results.0D.3306_13, but at the alignment of the ptr_info, which at this point is not initialised yet. - During the finalize of the first ccp phase, ptr_info of results.0D.3306_13 is initialized with align 16, based on the lattice value. - During the propagation of the second ccp phase, the align of the ptr_info of results.0D.3306_13 of 16 is used to propagate through to the comparison 'if (D.3309_16 == 0)', which makes sure the '16byte aligned' string is printed. - During the finalize of the second ccp phase, the alloca is folded, and the new declared array gets an align of 4 bytes.