On Sun, Sep 4, 2022 at 3:33 PM Iain Sandoe <i...@sandoe.co.uk> wrote:
>
> Hi,
>
> I am clearly missing something here … can someone point out where it is?
>
> https://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/Variable-Attributes.html#Variable%20Attributes
> in the discussion of applying this to structure fields:
>
> "The aligned attribute can only increase the alignment; but you can decrease
> it by specifying packed as well."
>
> Consider:
>
> struct odd {
> int * __attribute__((aligned(2))) a;
I think this applies the attribute to the type. For non-aggregate
types 'packed' is ignored. So the above
is equivalent to
typedef int *A __attribute__((aligned(2)));
struct odd {
A a;
char c;
};
> char c;
> };
>
> I would expect, given reading of the information on the aligned attribute,
> that the under-alignment of a would be ignored (since there is no packed
> attribute on either the field or the struct).
>
> However, on x86_64, powerpc64 linux and x86_64, powerpc Darwin, I see that
> the size of the struct is sizeof(pointer) + 2 and the alignment is 2.
>
> OTOH:
>
> struct OK {
> int __attribute__((aligned(2))) a;
> char c;
> };
>
> behaves as expected (the under-alignment is ignored, silently).
>
> as does this…
>
> struct maybe {
> int *a __attribute__((aligned(2)));
> char c;
> };
Where for both of these cases the attribute applies to the FIELD_DECL.
The documentation refers to
alignment of fields, not the alignment of types.
At least that's my understanding of this issue.
IIRC clang has issues when matching GCC attribute parsing rules, esp.
when applied to pointer types.
Richard.
> * the type of the pointer does not seem to be relevant (i.e. AFAICT the
> behaviour is the same for char * etc.)
>
> Is there some special rule about pointers that I have not found ?
>
> [it’s making an ABI mismatch with clang, which treats the int * as expected
> from the documentation quoted above]
>
> cheers
> Iain
>
>
>
