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: [email protected]
ReportedBy: [email protected]
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.
