[Bug driver/22600] New: Exit code should be different from 1 for internal compiler error

[Bug driver/22600] New: Exit code should be different from 1 for internal compiler error

[flash at pobox dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1334 bytes --]

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.

-- 
           Summary: Exit code should be different from 1 for internal
                    compiler error
           Product: gcc
           Version: 4.0.1
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: driver
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: flash at pobox dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22600

[Bug driver/22600] Exit code should be different from 1 for internal compiler error

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-21 22:12 -------
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/

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22600

[Bug driver/22600] Exit code should be different from 1 for internal compiler error

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-21 22:14 -------
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.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22600

[Bug driver/22600] Exit code should be different from 1 for internal compiler error

[reichelt at gcc dot gnu dot org]

------- Additional Comments From reichelt at gcc dot gnu dot org  2005-07-22 14:36 -------
We really do want this.
See the thread in http://gcc.gnu.org/ml/gcc/2005-02/msg00953.html


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |reichelt at gcc dot gnu dot
                   |dot org                     |org
             Status|UNCONFIRMED                 |ASSIGNED
  GCC build triplet|i686-pc-linux-gnu           |
   GCC host triplet|i686-pc-linux-gnu           |
 GCC target triplet|i686-pc-linux-gnu           |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22600

[Bug driver/22600] Exit code should be different from 1 for internal compiler error

[flash at pobox dot com]

------- Additional Comments From flash at pobox dot com  2005-07-22 16:04 -------
    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.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22600

[Bug driver/22600] Exit code should be different from 1 for internal compiler error

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-22 16:48 -------
(In reply to comment #5)
I should mention that we do print out the line/file which an assert fails inside gcc.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22600

[Bug driver/22600] Exit code should be different from 1 for internal compiler error

[flash at pobox dot com]

------- Additional Comments From flash at pobox dot com  2005-07-23 05:10 -------
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.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22600

[Bug driver/22600] Exit code should be different from 1 for internal compiler error

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2005-09-08 03:07 -------
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.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22600

[Bug driver/22600] Exit code should be different from 1 for internal compiler error

[patchapp at dberlin dot org]

------- Comment #9 from patchapp at dberlin dot org  2006-03-19 21:03 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22600

[Bug driver/22600] Exit code should be different from 1 for internal compiler error

[reichelt at gcc dot gnu dot org]

------- Comment #10 from reichelt at gcc dot gnu dot org  2006-03-22 19:36 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22600

[Bug driver/22600] Exit code should be different from 1 for internal compiler error

[reichelt at gcc dot gnu dot org]

------- Comment #11 from reichelt at gcc dot gnu dot org  2006-03-22 20:14 -------
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.


-- 

reichelt at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.2.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22600