[PATCH 2/2] Add patch for debugging compiler ICEs.
Joseph S. Myers
Thu Sep 18 22:17:00 GMT 2014
On Thu, 11 Sep 2014, Maxim Ostapenko wrote:
> In general, when cc1 or cc1plus ICE-es, we try to reproduce the bug by running
> compiler 3 times and comparing stderr and stdout on each attempt with
> respective ones that were gotten as the result of previous compiler run (we
> use temporary dump files to do this). If these files are identical, we add GCC
> configuration (e.g. target, configure options and version), compiler command
> line and preprocessed source code into last dump file, containing backtrace.
> Following Jakub's approach, we trigger ICE_EXIT_CODE instead of
> FATAL_EXIT_CODE in case of DK_FATAL error to differ ICEs from other fatal
> errors, so try_generate_repro routine will be able to run even if fatal_error
> occurred in compiler.
I still don't understand what's going on here with exit codes.
Suppose cc1 calls fatal_error (not for an ICE, not -Wfatal-errors - a
normal DK_FATAL arising from a call to fatal_error). What exit code does
it exit with? What path leads to that exit code? How does the driver
distinguish this from an ICE?
Suppose cc1 calls internal_error. What exit code does it exit with? What
path leads to that exit code? How does the driver distinguish this from a
call to fatal_error?
What about the above exit codes was different before the patch, that means
the driver ICE detection can only work given the diagnostic.c changes?
Joseph S. Myers
More information about the Gcc-patches