From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 4ADA43858024; Thu, 16 Feb 2023 19:20:57 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4ADA43858024 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1676575257; bh=l17ZetnPher/HMEUo79m+KAdEshg6y1bjfTR9Aiy8mQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=KDNOYwdQEaY3BD7R9Lhe4HVXyApQvdXw01JTIvD8gORne8kXKXOCT3EKdGCxoWKfX ZkSJnGhKdisTZIvwM+3i//TTcq5j8AJJ3aj4/GXEsEkZa14UJ7CnQMeOWkA+orSBST yql9cM3u/A8SSFvI8fMyrCHFPBoyG4JT7U+Hi8eg= From: "joseph at codesourcery dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/108796] Can't intermix C2x and GNU style attributes Date: Thu, 16 Feb 2023 19:20:56 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: rejects-valid X-Bugzilla-Severity: normal X-Bugzilla-Who: joseph at codesourcery dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108796 --- Comment #8 from 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 mi= x=20 > > anywhere with other declaration specifiers), but standard attributes=20 > > aren't declaration specifiers; rather, they come in specified positions= =20 > > relative to declaration specifiers (the semantics before and after the= =20 > > declaration specifiers are different), and in the middle isn't such a=20 > > position. >=20 > 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=20 here*, not necessarily in all other cases. The position in relation to=20 other declaration specifiers does not matter in those examples. Whereas a= =20 standard attribute at the start of declaration specifiers appertains to=20 the entity declared, while a standard attribute at the end of declaration=20 specifiers appertains to the type in those declaration specifiers. That=20 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.= =20=20 While __attribute__((noreturn)) means exactly the same thing in both=20 locations - it appertains to the function (and you could also have it in=20 the middle of other declaration specifiers, with the same meaning). So=20 the two kinds of attributes are not interchangable, and the semantics for=20 arbitrary mixtures would not be clear. It might work to have arbitrary mixtures in the struct context. But in=20 the void func(int *ip) __attribute__((nonnull(1))); context you again have attributes appertaining to different things: a GNU=20 attribute in that position is in a particular position *in a declaration*=20 (after any asm ("identifier"), before an initializer), and appertains to=20 the entity declared, whereas a standard attribute in such a position is=20 part of the declarator (immediately following a function-declarator or=20 array-declarator) and appertains to the function type - although they look= =20 superficially like the same case in simple examples such as this one, they= =20 aren't at all. And so again it would be unclear what attributes in=20 arbitrary mixtures should appertain to. (There is then logic in GCC to handle __attribute__ that, according to the= =20 syntax, should appertain to a particular entity, so that it's instead=20 applied to some other related entity; for example, moving an attribute=20 from a declaration to its type. This is deliberately *not* done for [[]]=20 attribute syntax; those attributes are expected to be written in a correct= =20 location for the entity they appertain to.)=