http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56335
Bug #: 56335
Summary: Optimization assumes __attribute__((aligned(N)))
always works.
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bro...@gcc.gnu.org
Created attachment 29460
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29460
(Generated assembly code)
As recently discussed in bug 56334, the documentation for
__attribute__((aligned(N))) notes that it does not necessarily produce the
requested alignment for static variables: "On many systems, the linker is only
able to arrange for variables to be aligned up to a certain maximum alignment.
(For some linkers, the maximum supported alignment may be very very small.)"
However, it appears that GCC itself has not read this documentation!
Consider this trivial .c file:
#define N (1<<27)
static float __attribute__((aligned(N))) a[128];
void foo()
{
if ((unsigned long) a % N == 0)
bar(a);
else
bar_unaligned(a);
}
We are not actually going to get this static array aligned to a 128-megabyte
alignment (especially if this goes into a shared library), but GCC nonetheless
eliminates the branch and possible call to bar_unaligned. See, for instance,
the output of this command line (where align5.c is the above file):
i686-pc-linux-gnu-gcc -O2 -S -fpic align5.c -o align5.s
There is clearly no reference to bar_unaligned in the generated assembly,
indicating that it has been optimized out.
