This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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 "" };
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.
-- Mark Mitchell CodeSourcery, LLC mark@codesourcery.com (916) 791-8304
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |