This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Issue with attribute ((aligned)) ?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]