* [Bug c/108796] GCC 13 accepts [[noreturn]] attribute without -std=c2x
2023-02-15 3:07 [Bug c/108796] New: GCC 13 accepts [[noreturn]] attribute without -std=c2x sam at gentoo dot org
@ 2023-02-15 3:10 ` sam at gentoo dot org
2023-02-15 3:11 ` sam at gentoo dot org
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: sam at gentoo dot org @ 2023-02-15 3:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796
Sam James <sam at gentoo dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Sam James <sam at gentoo dot org> ---
I asked on #gcc and this is intentional, it seems.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/108796] GCC 13 accepts [[noreturn]] attribute without -std=c2x
2023-02-15 3:07 [Bug c/108796] New: GCC 13 accepts [[noreturn]] attribute without -std=c2x sam at gentoo dot org
2023-02-15 3:10 ` [Bug c/108796] " sam at gentoo dot org
@ 2023-02-15 3:11 ` sam at gentoo dot org
2023-02-15 3:44 ` sam at gentoo dot org
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: sam at gentoo dot org @ 2023-02-15 3:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796
--- Comment #2 from Sam James <sam at gentoo dot org> ---
Sorry, for completeness, I meant to include:
```
$ gcc-12 -O2 /tmp/foo.c # ditto with -std=c89
/tmp/foo.c:3:1: warning: 'noreturn' attribute ignored [-Wattributes]
3 | [[noreturn]] void foo(void) {
| ^
``
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/108796] GCC 13 accepts [[noreturn]] attribute without -std=c2x
2023-02-15 3:07 [Bug c/108796] New: GCC 13 accepts [[noreturn]] attribute without -std=c2x sam at gentoo dot org
2023-02-15 3:10 ` [Bug c/108796] " sam at gentoo dot org
2023-02-15 3:11 ` sam at gentoo dot org
@ 2023-02-15 3:44 ` sam at gentoo dot org
2023-02-15 3:46 ` pinskia at gcc dot gnu.org
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: sam at gentoo dot org @ 2023-02-15 3:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796
Sam James <sam at gentoo dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|INVALID |DUPLICATE
--- Comment #3 from Sam James <sam at gentoo dot org> ---
*** This bug has been marked as a duplicate of bug 101682 ***
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/108796] GCC 13 accepts [[noreturn]] attribute without -std=c2x
2023-02-15 3:07 [Bug c/108796] New: GCC 13 accepts [[noreturn]] attribute without -std=c2x sam at gentoo dot org
` (2 preceding siblings ...)
2023-02-15 3:44 ` sam at gentoo dot org
@ 2023-02-15 3:46 ` pinskia at gcc dot gnu.org
2023-02-15 3:47 ` [Bug c/108796] Can't intermix C2x and GNU style attributes pinskia at gcc dot gnu.org
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-02-15 3:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|DUPLICATE |---
Status|RESOLVED |UNCONFIRMED
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Actually in this case it is slightly different.
Let me reopen it for a second.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/108796] Can't intermix C2x and GNU style attributes
2023-02-15 3:07 [Bug c/108796] New: GCC 13 accepts [[noreturn]] attribute without -std=c2x sam at gentoo dot org
` (3 preceding siblings ...)
2023-02-15 3:46 ` pinskia at gcc dot gnu.org
@ 2023-02-15 3:47 ` pinskia at gcc dot gnu.org
2023-02-15 21:02 ` joseph at codesourcery dot com
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-02-15 3:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|GCC 13 accepts [[noreturn]] |Can't intermix C2x and GNU
|attribute without -std=c2x |style attributes
--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Simple testcase:
__attribute__((noreturn)) [[noreturn]]
void foo(void) {
while(true);
}
The C++ front-end accepts this but not the C front-end.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/108796] Can't intermix C2x and GNU style attributes
2023-02-15 3:07 [Bug c/108796] New: GCC 13 accepts [[noreturn]] attribute without -std=c2x sam at gentoo dot org
` (4 preceding siblings ...)
2023-02-15 3:47 ` [Bug c/108796] Can't intermix C2x and GNU style attributes pinskia at gcc dot gnu.org
@ 2023-02-15 21:02 ` joseph at codesourcery dot com
2023-02-16 13:14 ` aaron at aaronballman dot com
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: joseph at codesourcery dot com @ 2023-02-15 21:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796
--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/108796] Can't intermix C2x and GNU style attributes
2023-02-15 3:07 [Bug c/108796] New: GCC 13 accepts [[noreturn]] attribute without -std=c2x sam at gentoo dot org
` (5 preceding siblings ...)
2023-02-15 21:02 ` joseph at codesourcery dot com
@ 2023-02-16 13:14 ` aaron at aaronballman dot com
2023-02-16 19:20 ` joseph at codesourcery dot com
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: aaron at aaronballman dot com @ 2023-02-16 13:14 UTC (permalink / raw)
To: gcc-bugs
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 joseph@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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/108796] Can't intermix C2x and GNU style attributes
2023-02-15 3:07 [Bug c/108796] New: GCC 13 accepts [[noreturn]] attribute without -std=c2x sam at gentoo dot org
` (6 preceding siblings ...)
2023-02-16 13:14 ` aaron at aaronballman dot com
@ 2023-02-16 19:20 ` joseph at codesourcery dot com
2023-02-16 20:06 ` aaron at aaronballman dot com
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: joseph at codesourcery dot com @ 2023-02-16 19:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796
--- Comment #8 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Thu, 16 Feb 2023, aaron at aaronballman dot com via Gcc-bugs wrote:
> > 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?
GNU attributes are declaration specifiers *in the previous examples given
here*, not necessarily in all other cases. The position in relation to
other declaration specifiers does not matter in those examples. Whereas a
standard attribute at the start of declaration specifiers appertains to
the entity declared, while a standard attribute at the end of declaration
specifiers appertains to the type in those declaration specifiers. That
is
[[noreturn]] void f();
declares a non-returning function f, but
void [[noreturn]] f();
applies the attribute (invalidly) to the type void, not to the function f.
While __attribute__((noreturn)) means exactly the same thing in both
locations - it appertains to the function (and you could also have it in
the middle of other declaration specifiers, with the same meaning). So
the two kinds of attributes are not interchangable, and the semantics for
arbitrary mixtures would not be clear.
It might work to have arbitrary mixtures in the struct context. But in
the
void func(int *ip) __attribute__((nonnull(1)));
context you again have attributes appertaining to different things: a GNU
attribute in that position is in a particular position *in a declaration*
(after any asm ("identifier"), before an initializer), and appertains to
the entity declared, whereas a standard attribute in such a position is
part of the declarator (immediately following a function-declarator or
array-declarator) and appertains to the function type - although they look
superficially like the same case in simple examples such as this one, they
aren't at all. And so again it would be unclear what attributes in
arbitrary mixtures should appertain to.
(There is then logic in GCC to handle __attribute__ that, according to the
syntax, should appertain to a particular entity, so that it's instead
applied to some other related entity; for example, moving an attribute
from a declaration to its type. This is deliberately *not* done for [[]]
attribute syntax; those attributes are expected to be written in a correct
location for the entity they appertain to.)
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/108796] Can't intermix C2x and GNU style attributes
2023-02-15 3:07 [Bug c/108796] New: GCC 13 accepts [[noreturn]] attribute without -std=c2x sam at gentoo dot org
` (7 preceding siblings ...)
2023-02-16 19:20 ` joseph at codesourcery dot com
@ 2023-02-16 20:06 ` aaron at aaronballman dot com
2023-02-16 22:34 ` aaron at aaronballman dot com
2024-01-14 10:26 ` pinskia at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: aaron at aaronballman dot com @ 2023-02-16 20:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796
--- Comment #9 from Aaron Ballman <aaron at aaronballman dot com> ---
> GNU attributes are declaration specifiers *in the previous examples given
> here*, not necessarily in all other cases.
Thanks for clarifying!
> (There is then logic in GCC to handle __attribute__ that, according to the
> syntax, should appertain to a particular entity, so that it's instead
> applied to some other related entity; for example, moving an attribute
> from a declaration to its type. This is deliberately *not* done for [[]]
> attribute syntax; those attributes are expected to be written in a correct
> location for the entity they appertain to.)
This touches on why I came to the decision I did in Clang. What `__attribute__`
will apply to is sometimes inscrutable and users are (perhaps) used to it
sliding around to whatever works. As you point out, `[[]]` doesn't have the
same behavior; it has strict appertainment. Because `__attribute__` doesn't
have strict appertainment, it did not seem like an issue for it to continue to
shift around to whatever makes sense. Thus `[[]]` will apply to what the
standard says it applies to, and `__attribute__` applies to whatever it should
apply to based on the attribute names in the specifier, but users don't have to
know whether they need to write `[[]] __attribute__(())` vs `__attribute__(())
[[]]`. (Clang also supports `__declspec`, so there are more combinations to
worry about sometimes.)
It really boils down to whether `__attribute__` is fundamentally a different
"thing" than `[[]]` and I couldn't convince myself they were different. The
result is, when the grammar allows consecutive attribute syntaxes, we parse all
allowed syntaxes in a loop so users can write them in an arbitrary order.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/108796] Can't intermix C2x and GNU style attributes
2023-02-15 3:07 [Bug c/108796] New: GCC 13 accepts [[noreturn]] attribute without -std=c2x sam at gentoo dot org
` (8 preceding siblings ...)
2023-02-16 20:06 ` aaron at aaronballman dot com
@ 2023-02-16 22:34 ` aaron at aaronballman dot com
2024-01-14 10:26 ` pinskia at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: aaron at aaronballman dot com @ 2023-02-16 22:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796
--- Comment #10 from Aaron Ballman <aaron at aaronballman dot com> ---
One other reason for the Clang behavior that may be worth mentioning is that
this helps users who wish to migrate away from `__attribute__` and towards
`[[]]`. Many (most?) uses of attributes end up behind a macro, so the user may
not even be aware which syntax is being used. Consider this contrived example:
```
// LibraryHeader.h
#if SOMETHING
#define FOO_ATTR __attribute__((foo))
#define BAR_ATTR __attribute__((bar))
#define BAZ_ATTR [[lib::baz]]
#elif SOMETHING_ELSE
...
#else
#define FOO_ATTR
#define BAR_ATTR
#define BAZ_ATTR
#endif
// UserCode.c
FOO_ATTR BAR_ATTR void func(void) { ... }
```
The user reading UserCode.c has no idea what attribute syntax is being used,
nor do they probably care all that much.
Under a strict parsing model, trying to add `BAZ_ATTR` to the declaration of
`func()` requires the user to be very aware of exactly what each macro expands
to, otherwise they might get the order wrong.
With a relaxed parsing model, the user doesn't have to care. Additionally, the
library header can migrate `BAR_ATTR` to `[[gnu::bar]]` syntax without also
migrating `FOO_ATTR` at the same time with less fear of breaking downstream
users due to attribute ordering, so this allows for gradual migration to a
newer syntax. (It's not "no fear" because `[[]]` has strict appertainment
rules, so it's possible for some attributes to break user code when migrating
from `__attribute__` to `[[]]` due to differences in appertainment.)
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/108796] Can't intermix C2x and GNU style attributes
2023-02-15 3:07 [Bug c/108796] New: GCC 13 accepts [[noreturn]] attribute without -std=c2x sam at gentoo dot org
` (9 preceding siblings ...)
2023-02-16 22:34 ` aaron at aaronballman dot com
@ 2024-01-14 10:26 ` pinskia at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-01-14 10:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gjl at gcc dot gnu.org
--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 113387 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 12+ messages in thread