https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98586
David Malcolm <dmalcolm at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2021-01-07
--- Comment #1 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Thanks for filing this. I'm able to reproduce the issue by hacking in a
gcc_assert (0);
into that routine.
I looked at calling diagnostic_initialize.
Unfortunately, libgccjit supports being linked into multithreaded processes,
and it guards all of the regular compiler state with a single big mutex,
including the diagnostic subsystem (and the "global_dc" pointer implicitly used
by fancy_abort). This failure is happening before the mutex is acquired.
Some possible solutions:
(a) guard more code with the mutex, and fix the ICE-handling to ensure that
diagnostic_initialize is called if need be so the final message can be printed
(b) make the ICE handler detect this case, and use a custom diagnostic context
for the final message (though it's accessing data outside of the mutex in this
case, albeit just one pointer that rarely changes, and in crash handling)
(c) don't use fancy_abort within libgccjit, perhaps overriding the defn of the
abort macro in system.h
(d) rewrite fancy_abort so that it detects the case somehow
(e) have a custom assertion macro for the parts of libgccjit that aren't
guarded by the mutex
I'm not sure yet what the best fix is.
