Alignment attribute has no effect under certain conditions

Bug #923397 reported by Mans Rullgard
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Linaro GCC
Fix Released
Medium
Ulrich Weigand
gcc
Fix Released
Medium

Bug Description

If an array definition with unspecified size and an alignment attribute is preceded by an extern declaration without the alignment attribute, the alignment attribute is ignored.

Example:

extern const int foo[];
const int __attribute__((aligned(16))) foo[] = { 0 };

Compiling this with Linaro GCC 4.6 (2012.01 release) results in an object file whose .rodata section has a required alignment of only 4 bytes. With Linaro GCC 4.5 and FSF GCC 4.6.2, the correct 16-byte alignment is specified in the output.

Specifying a size in the extern declartion or the definition (or both) also gives the correct result.

Revision history for this message
Asa Sandahl (asa-sandahl) wrote :

Thank you for the bug report. I've confirmed this with gcc-linaro-4.6-2012.01 on ARM:

asa-san@ursa4:~/bugs/alignment$ ~/bench/cbuild/slaves/ursa4/gcc-linaro-4.6-2012.01/gcc-binary/bin/gcc -c example.c
asa-san@ursa4:~/bugs/alignment$ readelf -t example.o
There are 11 section headers, starting at offset 0x108:

Section Headers:
  [Nr] Name
       Type Addr Off Size ES Lk Inf Al
       Flags
...
  [ 4] .rodata
       PROGBITS 00000000 000034 000004 00 0 0 4
       [00000002]: ALLOC
...

The work-around, as stated in the ticket, is to specify the size of the array.

The fault also exists in a late revisions of FSF trunk (gcc-4.7~svn183205).
The fault does not exist in gcc-linaro-4.5-2012.01.
The fault did not exist in gcc-linaro-4.6-2011.12. Investigation is needed to decide in which revision of gcc-linaro-4.6 the fault was introduced.

I've set it to medium priority for now, since there is a work around.

Changed in gcc-linaro:
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
Ramana Radhakrishnan (ramana) wrote :

This regression appears to have come from the upstream merge in 2012.01 since I can reproduce this with the FSF 4.6 branch .

Ramana

Revision history for this message
Ulrich Weigand (uweigand) wrote :

The regression was introduced by the following patch:
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00374.html

I've raised the issue on the gcc-patches list.

Changed in gcc-linaro:
assignee: nobody → Ulrich Weigand (uweigand)
Revision history for this message
In , Jakub-gcc (jakub-gcc) wrote :

extern const int v1[];
const int __attribute__((aligned(16))) v1[] = { 0 };
extern const int __attribute__((aligned(16))) v2[];
const int v2[] = { 0 };
extern const int __attribute__((aligned(16))) v3[];
const int __attribute__((aligned(16))) v3[] = { 0 };
const int __attribute__((aligned(16))) v4[] = { 0 };
int test[(__alignof__ (v4) != __alignof__ (v1)/* { dg-bogus "is negative" } */
 || __alignof__ (v4) != __alignof__ (v2)
 || __alignof__ (v4) != __alignof__ (v3)) ? -1 : 0];

fails with gcc 4.7, worked with 4.6, but it looks like the actual bug is of an earlier date, when DECL_USER_ALIGN bit has been moved from tree_decl_common etc.
down into tree_base.

Revision history for this message
In , Jakub-gcc (jakub-gcc) wrote :

Created attachment 26621
gcc47-pr52181.patch

Untested fix. The testcase shows that the C++ FE has a similar bug, but in the other direction, when olddecl has aligned attribute and newdecl doesn't.

Revision history for this message
Ulrich Weigand (uweigand) wrote :
Revision history for this message
In , Uweigand-gcc (uweigand-gcc) wrote :

The regression is present on tip of 4.6 branch as well, exposed by recent backports from mainline.

Changed in gcc-linaro:
status: Triaged → In Progress
Revision history for this message
In , Jakub-gcc (jakub-gcc) wrote :

Author: jakub
Date: Tue Feb 14 06:15:35 2012
New Revision: 184193

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184193
Log:
 PR c/52181
 * c-decl.c (merge_decls): Copy DECL_USER_ALIGN bit from olddecl to
 newdecl.

 * decl.c (duplicate_decls): If olddecl has bigger DECL_ALIGN than
 newdecl, copy DECL_ALIGN to newdecl and or DECL_USER_ALIGN bits.

 * c-c++-common/pr52181.c: New test.

Added:
    trunk/gcc/testsuite/c-c++-common/pr52181.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/c-decl.c
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/decl.c
    trunk/gcc/testsuite/ChangeLog

Revision history for this message
In , Jakub-gcc (jakub-gcc) wrote :

Fixed.

Revision history for this message
In , Uweigand-gcc (uweigand-gcc) wrote :

Thanks for the quick fix! Are you planning to backport to 4.6 as well?

Revision history for this message
Ulrich Weigand (uweigand) wrote :

Now fixed upstream in mainline. Backport to 4.6 branch still outstanding.

Revision history for this message
In , Jakub-gcc (jakub-gcc) wrote :

Author: jakub
Date: Tue Feb 14 23:34:34 2012
New Revision: 184242

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184242
Log:
 Backported from mainline
 2012-02-14 Jakub Jelinek <email address hidden>

 PR c/52181
 * c-decl.c (merge_decls): Copy DECL_USER_ALIGN bit from olddecl to
 newdecl.

 * decl.c (duplicate_decls): If olddecl has bigger DECL_ALIGN than
 newdecl, copy DECL_ALIGN to newdecl and or DECL_USER_ALIGN bits.

 * c-c++-common/pr52181.c: New test.

Added:
    branches/gcc-4_6-branch/gcc/testsuite/c-c++-common/pr52181.c
Modified:
    branches/gcc-4_6-branch/gcc/ChangeLog
    branches/gcc-4_6-branch/gcc/c-decl.c
    branches/gcc-4_6-branch/gcc/cp/ChangeLog
    branches/gcc-4_6-branch/gcc/cp/decl.c
    branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

Revision history for this message
Ulrich Weigand (uweigand) wrote :

Fix is now backported to upstream 4.6 branch. This means the fix should get merged into Linaro GCC 4.6 automatically for the next release.

Michael Hope (michaelh1)
Changed in gcc-linaro:
milestone: none → 4.6-2012.03
Changed in gcc:
importance: Unknown → Medium
status: Unknown → Fix Released
Michael Hope (michaelh1)
Changed in gcc-linaro:
status: In Progress → Fix Committed
Michael Hope (michaelh1)
Changed in gcc-linaro:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.