public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/56335] New: Optimization assumes __attribute__((aligned(N))) always works.
@ 2013-02-15 6:31 brooks at gcc dot gnu.org
2013-02-15 9:28 ` [Bug c/56335] " rguenth at gcc dot gnu.org
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: brooks at gcc dot gnu.org @ 2013-02-15 6:31 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug c/56335] Optimization assumes __attribute__((aligned(N))) always works.
2013-02-15 6:31 [Bug tree-optimization/56335] New: Optimization assumes __attribute__((aligned(N))) always works brooks at gcc dot gnu.org
@ 2013-02-15 9:28 ` rguenth at gcc dot gnu.org
2013-02-15 15:47 ` joseph at codesourcery dot com
2024-04-09 4:45 ` pinskia at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-02-15 9:28 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug c/56335] Optimization assumes __attribute__((aligned(N))) always works.
2013-02-15 6:31 [Bug tree-optimization/56335] New: Optimization assumes __attribute__((aligned(N))) always works brooks at gcc dot gnu.org
2013-02-15 9:28 ` [Bug c/56335] " rguenth at gcc dot gnu.org
@ 2013-02-15 15:47 ` joseph at codesourcery dot com
2024-04-09 4:45 ` pinskia at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: joseph at codesourcery dot com @ 2013-02-15 15:47 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug c/56335] Optimization assumes __attribute__((aligned(N))) always works.
2013-02-15 6:31 [Bug tree-optimization/56335] New: Optimization assumes __attribute__((aligned(N))) always works brooks at gcc dot gnu.org
2013-02-15 9:28 ` [Bug c/56335] " rguenth at gcc dot gnu.org
2013-02-15 15:47 ` joseph at codesourcery dot com
@ 2024-04-09 4:45 ` pinskia at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-04-09 4:45 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-04-09 4:45 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-15 6:31 [Bug tree-optimization/56335] New: Optimization assumes __attribute__((aligned(N))) always works brooks at gcc dot gnu.org
2013-02-15 9:28 ` [Bug c/56335] " rguenth at gcc dot gnu.org
2013-02-15 15:47 ` joseph at codesourcery dot com
2024-04-09 4:45 ` pinskia at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).