Ping.
On 09/11/2014 08:20 PM, Maxim Ostapenko wrote:
> 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.
>>
>