This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Issue with attribute ((aligned)) ?
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: gcc at gcc dot gnu dot org
- Date: Tue, 17 Jun 2014 18:39:32 +0200 (CEST)
- Subject: Issue with attribute ((aligned)) ?
- Authentication-results: sourceware.org; auth=none
Hello,
in comparing ABI conformance across compilers I ran across an issue where
GCC's behavior does appear to deviate from the manual.
In http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html, we have:
aligned (alignment)
This attribute specifies a minimum alignment for the variable or
structure field, measured in bytes.
[snip]
When used on a struct, or struct member, the aligned attribute can
only increase the alignment; in order to decrease it, the packed
attribute must be specified as well.
However, the following test case:
struct test
{
int * __attribute__ ((aligned (2))) a;
};
int main (void)
{
printf ("align: %d\n", (int)__alignof__(struct test));
}
outputs an alignment of 2. Based on the above wording, I would
have expected an alignment of 8 on a 64-bit machine. (And the
latter is indeed what LLVM, for example, implements.)
Note that this appears to happen only in the specific
declaration above; things work as documented when using e.g.
int __attribute__ ((aligned (2))) a;
or even
int *a __attribute__ ((aligned (2)));
In fact, this also raises the question what the exact semantics
of the above construct is; according to the manual in seems that
int * __attribute__ ((aligned (2))) a;
ought to define a (default-aligned) pointer to a 2-aligned int,
in which case the above distinction would be moot and we'd
expect __alignof__(struct test) to be 8 in any case.
(see http://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html)
That does't appear to be what's happening either; with
struct test x;
printf ("align: %d %d\n", (int)__alignof__(x.a), (int)__alignof__(*x.a));
I get 2 for __alignof__(x.a) and 4 for __alignof__(*x.a), so it
does appear the alignment is being applied (if incorrectly) to
the pointer, not the pointed-to data ... (LLVM actually also
does it this way.)
Is this a bug in GCC (or the documentation)?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com