public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: Iain Sandoe <iain@sandoe.co.uk>
Cc: GCC Development <gcc@gcc.gnu.org>
Subject: Re: An odd case with structure field alignment.
Date: Mon, 5 Sep 2022 10:53:43 +0200	[thread overview]
Message-ID: <CAFiYyc3JrtfMLdYtRT=1jo5QCCgUG2-ZyazBso8KD5GCtJGO6g@mail.gmail.com> (raw)
In-Reply-To: <88B0BAB2-A649-406E-B536-EE18431858F1@sandoe.co.uk>

On Sun, Sep 4, 2022 at 3:33 PM Iain Sandoe <iain@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
>
>
>

  reply	other threads:[~2022-09-05  8:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-04 13:32 Iain Sandoe
2022-09-05  8:53 ` Richard Biener [this message]
2022-09-05  9:06   ` Iain Sandoe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFiYyc3JrtfMLdYtRT=1jo5QCCgUG2-ZyazBso8KD5GCtJGO6g@mail.gmail.com' \
    --to=richard.guenther@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=iain@sandoe.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).