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.weig...@de.ibm.com
