I'm not sure what exactly you are expecting. With the proper compiler flags
unknown (or mispelled) attributes give a warning and then you can even turn
on warnings as errors. If you want to force all compilers to support
vendor-specific attributes from other vendors you have to put those into
the standard. I personally like to write portable C++ code which is why you
will never get all people to agree on non-ignorable attributes.

As long as you are using GCC-specific attributes and the GCC as compiler,
it would be quite stupid for GCC not to respect their own attributes. But,
this is a problem of GCC and not of the standards committee. If you are
relying on compiler-specific extensions, go to the compiler vendor. I don't
think that any sane compiler will ignore certain attributes only sometimes.
I expect compilers to be consistent in this respect. And if they are not, I
don't want to use that compiler (or maybe just not that attribute). With
this in mind, I don't see why we need to force non-ignorable attributes.
Would it help if the standard required that each compiler makes their own
vendor-specific attributes non-ignorable?

On Fri, Feb 13, 2026 at 11:34 AM David Brown via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hi,
>
> The difference with comments (and code that is disabled by pre-processor
> conditional compilation) is that the user knows he/she is writing a
> comment. There is an obvious difference between :
>
> [[nodiscard]] int foo();
>
> and
>
> int foo(); // Don't throw away the return value here
>
>
> As far as the claimed 99% / 1% split goes, I do not think it is remotely
> realistic. I have no statistics to back up any numbers, but I quick
> scan of a relatively recent project of mine shows 30 uses of
> vendor-specific attributes. Of those, two could be ignored at cost to
> speed rather than code correctness. (And given that those functions are
> for turning off power drivers in the event of an emergency, correct but
> slow code could still mean disaster.) About five of them are messing
> around with elf format symbols - ignoring them would lead to link-time
> errors. Another eight are used to control inlining - /essential/
> inlining due to the way the code works on this embedded system, not just
> for code efficiency. There are about 4 "noreturn" attributes, which
> could be ignored at the cost of poorer code generation and, more
> importantly, poorer static error checking.
>
>
> I can accept that certain attributes can safely be ignored /sometimes/.
> If you are writing code that will be distributed in source form and
> compiled by different people with different tools and settings, then
> maybe it is acceptable for those other people to see your code as a
> finished, debugged black box - they don't need static error checking on
> it. You only need your [[nodiscard]] and [[gnu::format]] checks when
> developing the software, not for build-only compilation. But even then,
> those attributes must /not/ be ignored when you are doing some compiles
> - your development compiles.
>
>
> So perhaps the 99% / 1% split /is/ realistic - but the 99% is for
> attributes that must either never be ignored, or at least not be ignored
> during development builds.
>
>
> There are attributes that must never be ignored, ever, because they
> affect semantics, ABIs, data layout, etc. There are attributes that are
> for diagnostic and static error checking purposes only, which can be
> ignored in non-development builds but must not be ignored in development
> builds. There are attributes that only affect code efficiency, not code
> correctness, so they could safely (but annoyingly) be ignored by some
> tools. There are attributes that could be safely ignored on some
> platforms or for some programs, but which affect code correctness in
> other cases.
>
> It is possible that what is really needed here is some concept similar
> to enforcement policies for contracts - something to distinguish between
> when it is acceptable to ignore unimplemented attributes or skip the
> extra static error checks, and when it is not acceptable to do so.
>
> But a general "attributes are always ignorable" attitude just makes the
> whole thing useless. We've already got comments for that.
>
> David
>
>
>
>
> On 13/02/2026 09:33, Sebastian Wittmeier via Std-Proposals wrote:
> > Attributes are not the only part of the language which is ignored.
> >
> > The same is true for source code comments.
> >
> > Comments are often used for automatic documentation generation or other
> > annotations.
> >
> > If 99% of attributes are ignorable, should the 1% be implemented
> > differently (=not as attributes)?
> >
> > The ignore lists would be quite long, if all 99% of attributes have to
> > be defined as ignorable.
> >
> > If attributes can be marked as either in-place, it is another possible
> > source of error to mark one in the wrong way.
> >
> > I agree that this situation can be improved a bit, but I disagree that
> > how it is currently done was wrong.
> >
> > -----Ursprüngliche Nachricht-----
> > *Von:* David Brown via Std-Proposals <
> std-proposals_at_[hidden]>
> > *Gesendet:* Fr 13.02.2026 09:31
> > *Betreff:* Re: [std-proposals] Named Return Value
> Optimisation [[nrvo]]
> > *An:* std-proposals_at_[hidden];
> > *CC:* David Brown <david.brown_at_[hidden]>;
> >
> > On 13/02/2026 07:03, Simon Schröder via Std-Proposals wrote:
> > >
> > >
> > >> On Feb 10, 2026, at 8:06 PM, Thiago Macieira via Std-Proposals
> > <std-proposals_at_[hidden]> wrote:
> > >>
> > >> On Tuesday, 10 February 2026 10:55:23 Pacific Standard Time
> > Alejandro Colomar
> > >> via Std-Proposals wrote:
> > >>> But [[comp::attr]] has never been ignorable. That ship has not
> > sailed
> > >>> yet.
> > >>
> > >> Yes they have and are. If I put a [[gnu::noclone]] attribute on
> > a function and
> > >> compile with Clang, it just tells me:
> > >>
> > >> warning: unknown attribute 'gnu::noclone' ignored; did you mean
> > >> 'gnu::noinline'?
> > >>
> > > One good thing about C++ is that its source code can be portable
> > in general. If we require that vendor specific attributes cause a
> > compiler error we are forced to use macros instead. Sure, we might
> > not be able to link to a library compiled with a different compiler
> > that supports the attribute. But, as long as we compile everything
> > with the same compiler, it should work (in 99% of the cases) even if
> > we ignore attributes. We cannot require that msvc supports all gnu
> > attributes whenever new ones are introduced. In order to avoid this
> > we have a standard to define all attributes that should (but don’t
> > have to) be supported by every compiler. I believe that it is
> > sufficient to provide a diagnostic for foreign attributes and not
> > apply them.
> >
> > For many attributes, ignoring them on compilers that don't support
> them
> > is safe - a lot of attributes (standard or vendor-specific) are for
> > improved static error checking. Another lump are for optimisation.
> > But
> > there are also attributes that directly affect semantics and the
> > generated code or data structures. If a compiler fails to handle
> > these,
> > the result is code that does not do what the programmer intended. If
> > the programmer has used "[[gnu::interrupt]]", or "[[gnu::ms_abi]]"
> on a
> > function, and a compiler ignores it, the result is broken code -
> > probably silently broken until weird effects at run-time lead to
> > complete disaster. The only really correct handling of these
> > attributes
> > on a compiler that does not support them is a fatal compile-time
> error.
> > (The same applies to misspellings of such attributes.)
> >
> > I am really not happy about the attitude of ignoring attributes. I
> > don't write code just for the fun of it - if I put something in my
> > code,
> > I expect the compiler to pay attention to it. If I have written
> > something that the compiler can't understand or can't implement, I
> > expect it to tell me. I am fine with having a way for the
> > programmer to
> > explicitly tell the compiler that an attribute can be ignored, but
> the
> > default should not allow ignoring them. 99% of cases being okay is
> 1%
> > of cases being disaster.
> >
> >
> > As things stand with C++ today, compilers are left to fix this
> > "ignorable attributes" flaw (IMHO) that has crept into the standard.
> > gcc has both a "-Wignored-attributes" warning (for when the compiler
> > understands the attribute, but is ignoring it) and a "-Wattributes"
> > warning (for when the attribute is unknown - including other
> > vendor-specific attributes). These are both enabled by default
> (albeit
> > only as warnings, not as fatal errors). This is because the gcc
> > developers have understood that the C++ standards got this badly
> wrong,
> > and ignorable attributes are a severe disservice to C++ programmers.
> >
> > A quick check with godbolt suggests that most other C++ compilers are
> > similar, except MSVC that doesn't blink on bad attributes unless you
> > enable warnings (which of course any sane developer will do).
> >
> > Even with that, I would recommend that if you are writing code that
> > relies on vendor-specific attributes, you should use vendor-specific
> > syntax. If you write "__attribute__(("ms_abi"))" or
> > "__declspecl("fastcall"))", you are sure to force a compile-time
> error
> > if the code is used with a compiler that can't handle it. Of course
> > for
> > your cross-platform code you'll hide these behind macros and
> > conditional
> > compilation - but that's you, the programmer, making active choices
> and
> > checking things work correctly on those platforms. It is not the C++
> > standards lying back and saying "It's all cool, don't worry about it,
> > we'll let that stuff slide".
> >
> >
> >
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> >
> >
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>