[Bug tree-optimization/56335] New: Optimization assumes __attribute__((aligned(N))) always works.

["brooks at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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: unassigned@gcc.gnu.org
        ReportedBy: brooks@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.