[Bug c/81756] type attributes silently ignored on type declarations

[Bug c/81756] type attributes silently ignored on type declarations

[minipli at grsecurity dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81756

Mathias Krause <minipli at grsecurity dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jsm28 at gcc dot gnu.org,
                   |                            |minipli at grsecurity dot net

--- Comment #2 from Mathias Krause <minipli at grsecurity dot net> ---
It's even worse. All GNU attributes get ignored for type declarations. Standard
C attributes, however, are taken into account and I don't see the rationale
behind this? Joseph, do you remember?

The relevant documentation regarding this is even misleading. It states the
following at https://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html:
"""
You may specify type attributes in an enum, struct or union type declaration or
definition by placing them immediately after the struct, union or enum keyword. 
"""

Please note, how declarations are explicitly mentioned, making the reader
assume this, indeed, actually works.

In the very next sentence it gets even more misleading:
"""
You can also place them just past the closing curly brace of the definition,
but this is less preferred because logically the type should be fully defined
at the closing brace.
"""

This can be read as discouraging the use in definitions, implicitly implying
declarations are the preferred way to add attributes while, in fact,
declarations silently ignore these attributes. They get parsed, still, but not
attached to the type declaration at all.

The misleading behaviour can be shown by trying to compile this C code snippet:
```
struct __attribute__((aligned(64))) foo;
struct foo { char i; };

_Static_assert(__alignof__(struct foo) == 64, "decl attribute ignored!");
```

The attribute of the declaration in line 1 should be inherited by the
definition in line 2, making the assert in line 4 pass. However, basically all
versions of gcc fail the assert, as can be seen on godbolt:
https://godbolt.org/z/ssW7T363W

Clang seems to comply to gcc's documentation much better, starting as early as
of clang 3.2. Again, here's the godbolt link: https://godbolt.org/z/MnvzsvcGG

Newer versions of gcc supporting the C23 attribute syntax do pass the test when
specifying attributes using the standard syntax, as can be seen here:
https://godbolt.org/z/8Ee4E3exP

However, I don't see a reason why it should be limited to only the C23
attribute syntax. Especially, as the GNU syntax gets *silently* ignored and
clang already unconditionally excepts both variants.


The following change fixes -- at least from my understanding -- the broken
behaviour in gcc:
diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index 00f8bf4376e5..02cf46f199d7 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -4114,7 +4114,8 @@ c_parser_struct_or_union_specifier (c_parser *parser)
     c_parser_error (parser, "expected %<;%>");
   /* ??? Existing practice is that GNU attributes are ignored after
      the struct or union keyword when not defining the members.  */
-  ret = parser_xref_tag (ident_loc, code, ident, have_std_attrs, std_attrs,
+  ret = parser_xref_tag (ident_loc, code, ident, have_std_attrs || attrs,
+                        std_attrs ? chainon (std_attrs, attrs) : attrs,
                         false);
   return ret;
 }

It's far from a proper change, as there are more places that need to be adapted
to, for example, cover enums as well. However, it shows where things go wrong
and where the (still parsed!) (GNU only!) attributes get silently ignored. And
yes, the comment needs a change too.

If there's consent that gcc should follow Clang's lead and actually comply to
its own documentation, I can prepare a proper patch.

Thanks,
Mathias

[Bug c/81756] type attributes silently ignored on type declarations

[jsm28 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81756

--- Comment #3 from Joseph S. Myers <jsm28 at gcc dot gnu.org> ---
This sort of "???" comment about existing practice means that some past change
(in this case, the one adding support for [[]] attributes) was aiming to avoid
perturbing how the compiler behaved for constructs that were not the subject of
the change (in this case, __attribute__).

Silently ignoring attributes is not good, but it would be important to diagnose
cases where they cannot be respected, such as when the attributes appear after
the type was defined and are not consistent with the attributes in effect when
it was defined.

The documentation you refer to is intended to mean that "struct
__attribute__((...)) foo { ... }" is preferred to "struct foo { ... }
__attribute__((...))", not to suggest that the attributes should be used in a
declaration that does not define the tagged type.