https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119366
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dmalcolm at gcc dot gnu.org,
| |jakub at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed| |2025-03-19
Priority|P3 |P1
Ever confirmed|0 |1
Target Milestone|--- |15.0
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Most likely started with r15-5988-g5a022062d22e0bd6f8bb650ca109b0ca2d093796
The problem is the combination of -Wfatal-errors and
635 auto_urlify_attributes sentinel;
in decl_attributes (and perhaps other spots).
This temporarily changes global_diagnostic_context.m_urlifier, but changes it
to a non-static member of an automatic variable.
Now, without -Wfatal-errors, all works fine, the RAII class restores it back
and eventually diagnostic_context::finish
427 delete m_urlifier;
428 m_urlifier = nullptr;
which at that point is normally some new allocated class (or nullptr would be
fine too).
But with -Wfatal-errors, finish is invoked while the m_urlifier override is
still in place, so it invokes delete on an address of a non-static member in
automatic variable.
Now, gcc is (intentionally) built with -fno-rtti, so we can't use RTTI to find
out if m_urlifier is one of these overrides.
Perhaps add a virtual method which will return the urlifier pointer that
actually should be deleted? I.e. for urlifier it would just return this, but
for
attribute_urlifier would arrange to return m_old_urlifier? Of course that
would need some reshuffling, since that member is in a different class, not in
attribute_urlifier.
Rewriting the sentinels so that they don't use address of an automatic variable
but new something all the time and delete afterwards would be too costly, these
sentinels are encountered many times.
