while investigating a clang error when compiling the linux kernel i narrowed the problem down to what seems to be a gcc bug. what happens is that despite what the gcc documentation says about the aligned attribute, gcc does decrease structure field alignment even when the packed attribute is not specified. the attached example shows that the issue is only with the attribute attached to a typedef. the relevant part of the generated asm looks like this for gcc:

        movq    xx+8(%rip), %rax
        addq    x+4(%rip), %rax   <==== bug, should be +8
        addq    p+2(%rip), %rax   <==== should it be +4?
        addq    pp+4(%rip), %rax

and for clang:

        movq    xx+8(%rip), %rax
        addq    x+8(%rip), %rax
        addq    p+2(%rip), %rax
        addq    pp+4(%rip), %rax

the tested gcc versions so far:

  gcc version 4.4.5 (Gentoo 4.4.5 p1.0, pie-0.4.5)
  gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) 

note that fixing this bug will have a non-trivial effect on linux as this construct is relied upon throughout the compat layer (that implements transforming syscall parameters between 32 bit userland and the 64 bit kernel) so when gcc stops decreasing the natural alignment of these structure fields, all such code will have to be changed to explicitly use the packed attribute lest the kernel/userland syscall ABI break... only to run into the next issue in that the packed attribute on the structure ignores the aligned attribute in the typedef (see the +2 above), both in gcc and clang (given both compilers are affected, i'm not sure if this is a bug or feature). more interestingly, if the aligned attribute is on the structure field itself then it is properly taken into account, both in gcc and clang. so this looks like a fine mess to clean up if/when the root bug gets fixed.