From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp001-out.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) by sourceware.org (Postfix) with ESMTPS id 98CB038582B3 for ; Mon, 5 Sep 2022 09:06:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 98CB038582B3 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sandoe.co.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=sandoe.co.uk Received: (qmail 23775 invoked from network); 5 Sep 2022 09:06:12 -0000 X-APM-Out-ID: 16623687722377 X-APM-Authkey: 257869/1(257869/1) 2 Received: from unknown (HELO ?192.168.1.95?) (81.138.1.83) by smtp001.apm-internet.net with SMTP; 5 Sep 2022 09:06:12 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: An odd case with structure field alignment. From: Iain Sandoe In-Reply-To: Date: Mon, 5 Sep 2022 10:06:11 +0100 Cc: GCC Development Content-Transfer-Encoding: quoted-printable Message-Id: <4CE0F7B6-8253-46DF-AF97-98886BAED50E@sandoe.co.uk> References: <88B0BAB2-A649-406E-B536-EE18431858F1@sandoe.co.uk> To: Richard Biener X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Spam-Status: No, score=-8.5 required=5.0 tests=BAYES_00,KAM_COUK,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > On 5 Sep 2022, at 09:53, Richard Biener via Gcc = wrote: >=20 > On Sun, Sep 4, 2022 at 3:33 PM Iain Sandoe wrote: >>=20 >> Hi, >>=20 >> I am clearly missing something here =E2=80=A6 can someone point out = where it is? >>=20 >> = https://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/Variable-Attributes.html#Variab= le%20Attributes >> in the discussion of applying this to structure fields: >>=20 >> "The aligned attribute can only increase the alignment; but you can = decrease it by specifying packed as well." >>=20 >> Consider: >>=20 >> struct odd { >> int * __attribute__((aligned(2))) a; >=20 > I think this applies the attribute to the type. =20 That was what I wondered - but it does not seem to apply the = under-alignment to a non-pointer type ... > For non-aggregate > types 'packed' is ignored. So the above > is equivalent to >=20 > typedef int *A __attribute__((aligned(2))); >=20 > struct odd { > A a; > char c; > }; Which (for the record) works as expected on both compilers. >=20 >> char c; >> }; >>=20 >> 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). >>=20 >> 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. >>=20 >> OTOH: >>=20 >> struct OK { >> int __attribute__((aligned(2))) a; >> char c; >> }; However, this does _not_ treat the same sequence as =E2=80=9Ctypedef int = A __attribute__((aligned(2)))=E2=80=9D >> behaves as expected (the under-alignment is ignored, silently). >>=20 >> as does this=E2=80=A6 >>=20 >> struct maybe { >> int *a __attribute__((aligned(2))); >> char c; >> }; >=20 > 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. sure, but I can=E2=80=99t at the moment see a consistent rule to file a = bug about. > At least that's my understanding of this issue. >=20 > IIRC clang has issues when matching GCC attribute parsing rules, esp. > when applied to pointer types. probably; when I looked at the decls produced there seemed to be no way = to to tell the position of the attribute in the decl (so to decide if = it=E2=80=99s a type attr or a field attr). =E2=80=A6 possibly that means poking at the parser too=E2=80=A6= =20 attributes in aggregates are fun, for sure .. =20 Iain >=20 > Richard. >=20 >> * the type of the pointer does not seem to be relevant (i.e. AFAICT = the behaviour is the same for char * etc.) >>=20 >> Is there some special rule about pointers that I have not found ? >>=20 >> [it=E2=80=99s making an ABI mismatch with clang, which treats the int = * as expected from the documentation quoted above] >>=20 >> cheers >> Iain