https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110617
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |redi at gcc dot gnu.org
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=79459
Last reconfirmed| |2025-07-13
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
> >But sometimes we want only the effect for diagnostic,
>
> I think that is a bad idea.
I disagree, it's needed.
In the C++ standard library there are loads of functions which have
preconditions on pointer arguments being non-null, so we put
__glibcxx_assert(ptr != nullptr) in the function body, e.g. the
polymorphinc_allocator(memory_resource*) constructor. This diagnoses undefined
behaviour and so helps users find bugs in their code.
But learning of those bugs during development is far better than aborting at
runtime after the code is deployed. So we have [[gnu::nonnull]] on that
constructor, so that users are warned at compile-time if they pass null
pointers. But now the assertion in the constructor body is optimized away,
because
Users should not have to use -fisolate-erroneous-paths-attribute (which would
replace the __glibcxx_assert with a less descriptive trap) or
-fno-delete-null-pointer-checks (which pessimizes correct code, e.g. when using
the 'new' operator). Most users don't even know those options exist, nor that
they might be useful for libstdc++ code.
So libstdc++ just needs to remove the attribute, and users won't get warned at
compile time.
A diagnostic-only version of nonnull is wanted.
The diagnose_if attribute (Bug 79459) would be a more general solution that
would solve this problem.
