Steps: 93> /opt/gcc401chk/bin/g++ -pass-exit-codes ../cpp/bugfiles/error/EckelRob_104822.ii … ../jammed/Barney/eckel.cpp:2039: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. 94> echo $? [This uses my file for bug 22508.] Actual Result: 1 Expected Result: Anything but 1 or 0. For recursive crash testing, the return code for an internal compiler error should be distinguishable from that for correct rejection of incorrect code. As a workaround, I've been checking the output for the presence and absence of various patterns, but this is inelegant and subject to error. PalmSource bug 50522.
I don't see why it should be different than 1. It would only be helpful when you have automated builds but even then you need to look at the errors. and for recursive crash testing you need to look for a pattern still as you might hit a different bug. Here is a python script which I use as a wrapper: #!/usr/bin/python # Using delta debugging on GCC input #import psyco #from psyco.classes import * import commands import string import sys # Invoke GCC (status, output) = commands.getstatusoutput("/Users/pinskia/local.c/libexec/gcc/powerpc-apple- darwin7.9.0/4.1.0/cc1plus --param ggc-min-expand=0 --param ggc-min-heapsize=0 -quiet -O2 -Wfatal-errors %s 2>&1" % sys.argv[1]) # Determine outcome if status == 0: sys.exit(1) elif string.find(output, "Segmentation Fault") >= 0: sys.exit(0) else: sys.exit(1) ---- cut ---- You might want to look into delta for reducing testcases: http://www.cs.berkeley.edu/~dsw/
One more thing usually ICEs have better error messages than just Segmentation fault. some give the line number in GCC's source where it occurred.
We really do want this. See the thread in http://gcc.gnu.org/ml/gcc/2005-02/msg00953.html
Created attachment 9330 [details] Patch to return 3 upon ICEs I didn't want to post the patch until it's more complete, but as we have a PR now, I'll post it as a base for a discussion. With the attached patch the compiler returns the value 3 upon ICEs if it is passed the option "-pass-exit-codes". The patch lacks documentation and stuff for integration into the testsuite. A number of questions also occur: * What shall the exit code be (I chose it to be 3). * Where shall we define it (is system.h okay)? * Do we want to make -pass-exit-codes the default?
Looking for a string pattern in the output leaves you vulnerable to correctly-rejected files which happen to generate that pattern in an error message. That's probably less of an issue with GCC's hand- crafted test code, but it was a real problem with the PalmSource compiler (which admittedly has more verbose error reporting) when doing random crash-testing. Our compiler prints the line it's complaining about, so a comment about an internal error could give a false positive. GCC may not have that problem, but it might still get fooled by a file name. More generally, unless you know all the possible error strings, you might miss an error. So I also looked for the absence of the normal correct-rejection strings, which is also subject to false positives, until you get them all. OTOH, if you know that returning with exit code 1 actually means a normal rejection, then you don't get annoyed with tricky stuff like (in our case, at least) files named after error signals.
(In reply to comment #5) I should mention that we do print out the line/file which an assert fails inside gcc.
Thanks very much, patch 9330 works well (though I had to apply the second change in gcc.c manually, since someone changed commands[i].prog to commands[j].prog later than my copy of the 4.0.1 sources). I've added a check in my recursive crash-tester for a normal exit code with abnormal error text, or missing normal rejection text. It's encountered a couple dozen internal error so far, and they all returned something other than 0 or 1. I'm running it on our source tree over the weekend.
I think this is a good idea. I don't think we need a switch; this should just be the default. We also need a documentation update to mention this. And, I think the default ICE_EXIT_CODE shold be "2", unless we're already using that for something else. With those changes, I'll review and approve the patch for 4.2.
Subject: Bug number PR 22600 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01203.html
Subject: Bug 22600 Author: reichelt Date: Wed Mar 22 19:36:22 2006 New Revision: 112292 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112292 Log: PR driver/22600 * system.h (ICE_EXIT_CODE): New macro. * diagnostic.c (diagnostic_count_diagnostic): Exit with ICE_EXIT_CODE. (diagnostic_action_after_output): Likewise. * gcc.c (fatal_ice): New function. (execute): Use it instead of fatal. (fancy_abort): Likewise. * doc/invoke.texi (-pass-exit-codes): Document return code for ICEs. * fortran/error.c (gfc_fatal_error): Return ICE_EXIT_CODE instead of 4. Modified: trunk/gcc/ChangeLog trunk/gcc/diagnostic.c trunk/gcc/doc/invoke.texi trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/error.c trunk/gcc/gcc.c trunk/gcc/system.h
Fixed in mainline. I.e. the C and C++ frontend now return "4" if an ICE occurred, and a code less than 4 if a regular error occurred. (The Fortran frontend has been doing this already.) In order to see the exit code one has to pass the option -pass-exit-codes to the driver (gcc, g++ or gfortran). Unfortunatly the testsuite doesn't make use of the new exit codes yet. This problem is tracked in PR 26813.