https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796
Aaron Ballman <aaron at aaronballman dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aaron at aaronballman dot com
--- Comment #7 from Aaron Ballman <aaron at aaronballman dot com> ---
(In reply to jos...@codesourcery.com from comment #6)
> The logic is that GNU attributes are declaration specifiers (and can mix
> anywhere with other declaration specifiers), but standard attributes
> aren't declaration specifiers; rather, they come in specified positions
> relative to declaration specifiers (the semantics before and after the
> declaration specifiers are different), and in the middle isn't such a
> position.
How does that square with:
```
struct __attribute__((packed)) S { ... };
void func(int *ip) __attribute__((nonnull(1)));
```
where the GNU attribute is not written where a declaration specifier is
allowed?
FWIW, the Clang rationale for our behavior is that users don't really
distinguish between spelling an attribute with `[[]]` or spelling it with
`__attribute__` -- it's an attribute either way. We couldn't find a reason why
it made sense to force users to determine arbitrary parse ordering rules for
conceptually "identical" constructs. While not compatible with GCC's approach,
a correct usage in GCC is expected to also be a correct usage in Clang.
