This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Suggestion: Different exit code for ICE
- From: Janis Johnson <janis187 at us dot ibm dot com>
- To: Volker Reichelt <reichelt at igpm dot rwth-aachen dot de>
- Cc: gcc at gcc dot gnu dot org, mmitchel at gcc dot gnu dot org
- Date: Thu, 24 Feb 2005 09:24:22 -0800
- Subject: Re: Suggestion: Different exit code for ICE
- References: <200502241046.j1OAkIQK029909@relay.rwth-aachen.de>
On Thu, Feb 24, 2005 at 11:46:20AM +0100, Volker Reichelt wrote:
> Regressions that cause ICE's on invalid code often go unnoticed in the
> testsuite, since regular errors and ICE's both match { dg-error "" }.
> See for example g++.dg/parse/error16.C which ICE's since yesterday,
> but the testsuite still reports "PASS":
>
[snip]
>
> This calls for a more robust method IMHO.
> One way would be to make the testsuite smarter and make it recognize
> typical ICE patterns itself. This can indeed be done (I for example
> use it to monitor the testcases in Bugzilla, Phil borrowed the patterns
> for his regression tester).
>
> An easier way IMHO would be to return a different error code when
> encountering an ICE. That's only a couple of places in diagnostic.c
> and errors.c where we now have "exit (FATAL_EXIT_CODE);".
> We could return an (appropriately defined) ICE_ERROR_CODE instead.
> The testsuite would then just have to check the return value.
>
> What do you think?
I don't think that it's appropriate for any test to use { dg-error "" };
there should always be some substring of the expected message there. If
the message changes then tests need to be updated, but that's better
than not noticing when the message changes unexpectedly or, worse yet,
the message is for an ICE. A quick count, however, shows that 1022
tests use { dg-error "" }. Given that, using and detecting a different
error code for an ICE is an excellent idea.
Janis