On Thu, 13 Mar 2025, Jason Merrill wrote:
I'd be afraid that would be quite significant change of behavior everywhere,
something that C doesn't allow (like mixing std and GNU attributes in any
orders or [[]] __attribute__(()) [[]][[]] __attribute__(())
expression-statement). Or it would allow __attribute__(()) on while, do,
for, if, switch, ..., again something that wasn't accepted before.
Do you think those changes are undesirable? We've previously had to fix cases
where we were failing to support mixing of std and GNU attributes.
On 3/13/25 4:10 PM, Jakub Jelinek wrote:
I know, but we've never allowed GNU attributes on most of those, neither
does clang, we don't allow it in C and with the exception of
fallthrough/assume on empty statement and musttail on return we currently
even don't have any uses for it. If we start accepting it, we'd then
need to support it forever.
But, as you say, we already started accepting it for
fallthrough/assume/musttail; deciding to allow it in that case and not
in others seems weirdly inconsistent.
Moving the GNU attribute assume/fallthrough handling on empty statement handling
from cp_parser_expression_statement would regress
int bar (int x) { return x; }
void
foo (void)
{
if (__attribute__(()); true)
;
if (__attribute__((assume (bar (1)))); true)
;
// if (__attribute__((fallthrough)); true)
// ;
}
accepted by g++ 13 and 14 (fallthrough commented out, that is diagnosed
with error).
So in an init-statement we can use GNU attributes but not standard
attributes? Another strange inconsistency.
On 3/13/25 4:10 PM, Joseph Myers wrote:
Mixing attributes is problematic because of different semantics for
appertainment. For example, in
void func() ATTRS;
if ATTRS are standard attributes then they are part of the function
declarator and appertain to the function type, but if they are GNU
attributes then they are not part of the declarator, but rather appertain
to the declaration. This means completely different parts of the C parser
handle the different kinds of attributes in what superficially looks like
the same position (standard attributes handled in parsing a declarator,
GNU ones in parsing the declaration after the declarator - with more
complicated declarators such as functions returning pointers to arrays,
the locations can end up physically separated) and there would be no
coherent syntax or semantics for appertainment for mixed attributes there.
That's true within a declaration-statement, but at the beginning of a
declaration-statement, both appertain to any declarations. And at the
beginning of any other statement, both appertain to the statement. So I
don't think this concern applies to this case.
Jason
