https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98586
--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by David Malcolm <dmalc...@gcc.gnu.org>: https://gcc.gnu.org/g:387f6c15d303a8f8da508e419fea10a6ef0e2590 commit r11-6700-g387f6c15d303a8f8da508e419fea10a6ef0e2590 Author: David Malcolm <dmalc...@redhat.com> Date: Thu Jan 14 17:02:28 2021 -0500 Handle fancy_abort before diagnostic initialization [PR98586] If fancy_abort is called before the diagnostic subsystem is initialized, internal_error will crash internally in a way that prevents a useful message reaching the user. This can happen with libgccjit in the case of gcc_assert failures that occur outside of the libgccjit mutex that guards the rest of gcc's state, including global_dc (when global_dc may not be initialized yet, or might be in use by another thread). I tried a few approaches to fixing this as noted in PR jit/98586 e.g. using a temporary diagnostic_context and initializing it for the call to internal_error, however the more code that runs, the more chance there is for other errors to occur. The best fix appears to be to simply fall back to a minimal abort implementation that only relies on i18n, as implemented by this patch. gcc/ChangeLog: PR jit/98586 * diagnostic.c (diagnostic_kind_text): Break out this array from... (diagnostic_build_prefix): ...here. (fancy_abort): Detect when diagnostic_initialize has not yet been called and fall back to a minimal implementation of printing the ICE, rather than segfaulting in internal_error.
