From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) by sourceware.org (Postfix) with ESMTPS id 7BF19385703E for ; Mon, 5 Sep 2022 08:53:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7BF19385703E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x52a.google.com with SMTP id u6so10368083eda.12 for ; Mon, 05 Sep 2022 01:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date; bh=ywrCM5FXltYmitlwgRFpk2jhpLBPu0Qkeo3dgmVb9iY=; b=O0VBi7QWuhXL4KhMdr0CgD2jItheZcUsb+PSX6BwhdRolYn/dRrBg3SADuD5ihWfda kDR37VS/D5GGOy2E6J+//+ZxCAYV6iYWssjTDn4/LrZasNd4t58Hn5S/cpzDWnlMdRaK bKc5HrsJpIKz4V3y6uakiG1+Ji75/7UZSTZr66wxxK2r9t07ILQLeWPMayAYlOy96EOu KjnNuHPw4wleQUQdnwYbIzEiUX2tP7EUnVHnCJCcQLkA3csRDNkuVKwa3OEkzA5iRNwa omXs//j2xoRTQsSQtfw+ocKv3vQxwCR6L8ZGYYTDD/1FWSGV78YUDmCZ93xBi8UomW7i butw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=ywrCM5FXltYmitlwgRFpk2jhpLBPu0Qkeo3dgmVb9iY=; b=5cJpzPOjcxujXIpVV5r2HHrhIHj/UNBHHS5Q+/tpN1hJtm0kWJimIRbkYpDZB3+x0S HIOYeSNrVBc/TAiJSgOgjtg37uUSWJYGEV242aLKYS+7ml2I0Os3oR6yOX8OSFKg7Sd9 BRCp6/SIzndk+ESNt/cQhflcSnKkheNS7cUhu0vH/5ZrMwYGc8RSaqAl4PBpEh2/vUnB DW81fJa6RMO8WHkdFz8hM9hY4HGoGN5ectmpQRkvW8xW6fuZJ6H3j3oQ/JRVVD4bUmGQ zd4bbrZUBf4zFiRy1rE4CrLNT04rBU0kRUaT9icma/37jOmjGD2mbKAl6nkvmpvGCs8u w0OQ== X-Gm-Message-State: ACgBeo09z4SQeAAJK1IB+p7k4fTh0whYu2C7a+a+oIvbHkSUV4H72y39 59LoolXI0kdmeEL57IVtXfNy+BC3MqE3UqaQW8A+8t6/4oo= X-Google-Smtp-Source: AA6agR5sQqL9KeEi34RGfGsquhsfxvZU7s5V15bVpUBtXdAG4q1MZSqP/YKsRvMh79IrFBmaN3sbJ4b6XZpx61UEgII= X-Received: by 2002:a05:6402:550c:b0:443:7d15:d57f with SMTP id fi12-20020a056402550c00b004437d15d57fmr42287208edb.147.1662368035956; Mon, 05 Sep 2022 01:53:55 -0700 (PDT) MIME-Version: 1.0 References: <88B0BAB2-A649-406E-B536-EE18431858F1@sandoe.co.uk> In-Reply-To: <88B0BAB2-A649-406E-B536-EE18431858F1@sandoe.co.uk> From: Richard Biener Date: Mon, 5 Sep 2022 10:53:43 +0200 Message-ID: Subject: Re: An odd case with structure field alignment. To: Iain Sandoe Cc: GCC Development Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham 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 Sun, Sep 4, 2022 at 3:33 PM Iain Sandoe wrote: > > Hi, > > I am clearly missing something here =E2=80=A6 can someone point out where= it is? > > https://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/Variable-Attributes.html#Varia= ble%20Attributes > in the discussion of applying this to structure fields: > > "The aligned attribute can only increase the alignment; but you can decre= ase 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 tha= t 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=E2=80=A6 > > 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 b= ehaviour is the same for char * etc.) > > Is there some special rule about pointers that I have not found ? > > [it=E2=80=99s making an ABI mismatch with clang, which treats the int * a= s expected from the documentation quoted above] > > cheers > Iain > > >