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

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

[brooks at gcc dot 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.

[Bug c/56335] Optimization assumes __attribute__((aligned(N))) always works.

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56335

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-02-15
          Component|tree-optimization           |c
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-15 09:28:12 UTC ---
That's a bug in alignment attribute processing then.  It should not communicate
alignments that can not be reached to the middle-end.

Language lawyer question: Is __alignof__ then allowed to report a lower
alignment?  Or do we have to reject a testcase with a too large alignment
specification as invalid?

[Bug c/56335] Optimization assumes __attribute__((aligned(N))) always works.

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56335

--- Comment #2 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2013-02-15 15:47:00 UTC ---
See <http://gcc.gnu.org/ml/gcc-patches/2011-11/msg00841.html>, where I 
discuss what I think would be the appropriate checks for supported 
alignment (which I deferred for the initial implementation of _Alignas / 
_Alignof).

I think the checks should be errors for both the C11 _Alignas syntax and 
the __attribute__ syntax.

[Bug c/56335] Optimization assumes __attribute__((aligned(N))) always works.

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56335

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=87795,
                   |                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=89357
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED
   Target Milestone|---                         |9.3

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>	.comm	a,512,134217728


The linker should fail to link if it can't link to 128 MB here.

From JSM's email:
> MAX_OFILE_ALIGNMENT (presently just a warning),

That was PR 87795 and was fixed in r9-3979-g4c7bd36194e13c .

> an object with automatic storage duration has an alignment greater than MAX_STACK_ALIGNMENT

See PR 89357 which removed the constraint for C++ _Alignas as the middle-end
supports huge alignments now.

So closing as fixed for GCC 9.3.0.