Hi, Joseph,

Thanks for your review! I've added comments for new functions and 
replaced POSIX subprocess interfaces with libiberty's ones.

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.

We've noticed that on rare occasion a particularly severe segfault can 
cause GCC to abort without ICE-ing. These (hopefully rare) errors will 
be missed by our patch, because SIGSEGV handler is not able to catch the 
signal due to corrupted stack. It could make sense to allocate separate 
stack for SIGSEGV handler to resolve this situation.

-Maxim
On 09/10/2014 08:37 PM, Joseph S. Myers wrote:
> On Wed, 10 Sep 2014, Jakub Jelinek wrote:
>
>> On Tue, Sep 09, 2014 at 10:51:23PM +0000, Joseph S. Myers wrote:
>>> On Thu, 28 Aug 2014, Maxim Ostapenko wrote:
>>>
>>>> diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
>>>> index 0cc7593..67b8c5b 100644
>>>> --- a/gcc/diagnostic.c
>>>> +++ b/gcc/diagnostic.c
>>>> @@ -492,7 +492,7 @@ diagnostic_action_after_output (diagnostic_context *context,
>>>>   	real_abort ();
>>>>         diagnostic_finish (context);
>>>>         fnotice (stderr, "compilation terminated.\n");
>>>> -      exit (FATAL_EXIT_CODE);
>>>> +      exit (ICE_EXIT_CODE);
>>> Why?  This is the case for fatal_error.  FATAL_EXIT_CODE seems right for
>>> this, and ICE_EXIT_CODE wrong.
>> So that the driver can understand the difference between an ICE and other
>> fatal errors (e.g. sorry etc.).
>> Users are typically using the driver and for them it matters what exit code
>> is returned from the driver, not from cc1/cc1plus etc.
> Well, I think the next revision of the patch submission needs more
> explanation in this area.  What exit codes do cc1 and the driver now
> return for (normal error, fatal error, ICE), and what do they return after
> the patch, and how does the change to the fatal_error case avoid incorrect
> changes if either cc1 or the driver called fatal_error (as opposed to
> either cc1 or the driver having an ICE)?  Maybe that explanation should be
> in the form of a comment on this exit call, explaining why the
> counterintuitive use of ICE_EXIT_CODE in the DK_FATAL case is correct.
>