Hi Paul, On Wed, Dec 17, 2025 at 10:45:50AM -0800, Paul Eggert wrote: > On 2025-12-17 02:57, Alejandro Colomar wrote: > > > If you want something that will (mostly) work, you could check... > > int j(int) [[gnu::aligned(8)]]; // Attributed: int(int) > > I'm puzzled by that "Attribute: int(int)".
Small typo: s/Attribute/&d/
> What does that mean? Intuitively,
> I would think it would mean that (uintptr_t)j must be a multiple of 8,
Yes, that's what I'd interpret.
> but
> that's not what GCC does when I bump the 8 to 128.
I can reproduce it. It seems a GCC bug. It should probably either
diagnose or respect the requested alignment.
>
>
> > enum d {D} [[gnu::aligned(8)]] y; // Attributes can't go here
>
> C23 allows this declaration, and the attribute appertains to the enum type
> (though just for the declaration of y). GCC 15.2 issues a warning that it
> ignores the attribute, and so disagrees with C23. Although Clang doesn't
> support [[gnu::aligned(8)]] on types, it issues no diagnostic when I use a
> type-related attribute that it does support, like this:
>
> enum d {D} [[clang::annotate_type("x")]] y;
>
> and so perhaps Clang is following C23 here. However, as Aaron notes there
> are related examples where Clang doesn't seem to follow C23 - and Aaron
> thinks the C23 standard has a bug in this area.
>
> It's not a big deal (how many programs will do this sort of thing?) but
> either the C standard should be fixed (i.e., complicated) to allow the
> behavior of GCC and Clang (whatever those behaviors happen to be), or GCC
> and Clang should be fixed to conform to C23.
The latter is more likely.
Have a lovely night!
Alex
--
<https://www.alejandro-colomar.es>
signature.asc
Description: PGP signature
