Bug 56335 - Optimization assumes __attribute__((aligned(N))) always works.
Summary: Optimization assumes __attribute__((aligned(N))) always works.
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 4.8.0
: P3 normal
Target Milestone: 9.3
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2013-02-15 06:30 UTC by Brooks Moses
Modified: 2024-04-09 04:45 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2013-02-15 00:00:00


Attachments
(Generated assembly code) (421 bytes, application/octet-stream)
2013-02-15 06:30 UTC, Brooks Moses
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Brooks Moses 2013-02-15 06:30:47 UTC
Created attachment 29460 [details]
(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.
Comment 1 Richard Biener 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?
Comment 2 jsm-csl@polyomino.org.uk 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.
Comment 3 Andrew Pinski 2024-04-09 04:45:18 UTC
>	.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.