I ran into this on NetBSD 4.0; the crash said to report it to NetBSD.
When I did so, they said "Why don't you let _them_ know, then?", "them"
referring to you people.  However, gcc 4.0 does not have either the
bugs.html or the BUGS referred to by bugreport.texi, as far as I can
see.  When I looked at the webpage named in bugreport.texi, it suggests
using a "gccbug script".  There is no gccbug script as far as I can
see; the closest thing I see is gccbug.in.  When I run it, I get what I
suspect is a somewhat malformed bug report; I'm including it below,
after my signature, rather than sending it to gcc-gnats, to avoid
dropping bogus information in your bug database (send it there yourself
if you'd rather have it there).  I'm not sure what the missing
information should be, nor where to find it.  This is the stock NetBSD
4.0 compiler, which reports itself with --version as being "4.1.2
20061021 prerelease", on i386, though I suspect the bug actually
applies to any version using a recursive-descent parser.

/~\ The ASCII                           der Mouse
\ / Ribbon Campaign
 X  Against HTML                [EMAIL PROTECTED]
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

To: [EMAIL PROTECTED]
Subject: [dM] cc1 crash (SIGILL)
From: mouse
X-send-pr-version: 3.113
X-GNATS-Notify: 


>Submitter-Id:  net
>Originator:    der Mouse
>Organization:  Dis-
>Confidential:  no
>Synopsis:      cc1 crash on certain input
>Severity:      non-critical
>Priority:      low
>Category:      c
>Class:         ice-on-legal-code
>Release:       
>Environment:
System: NetBSD NetBSD-4-0.Rodents.Montreal.QC.CA 4.0 NetBSD 4.0 (GENERIC) #0: 
Sun Dec 16 00:20:10 PST 2007 [EMAIL 
PROTECTED]:/home/builds/ab/netbsd-4-0-RELEASE/i386/200712160005Z-obj/home/builds/ab/netbsd-4-0-RELEASE/src/sys/arch/i386/compile/GENERIC
 i386
host: @host@
build: @build@
target: @target@
configured with: @gcc_config_arguments@
>Description:
        cc1 crashes (with SIGILL in my test) on sufficiently extreme input.
>How-To-Repeat:
        echo int i = > z.c
        yes \( | sed -e 10000000q >> z.c
        echo 0 >> z.c
        yes \) | sed -e 10000000q >> z.c
        echo \; >> z.c
        gcc -c z.c
        cc: Internal error: Illegal instruction (program cc1)

        This is presumably just running the recursive-descent parser
        out of stack space, and, as such, is expected, but
        bugreport.texi says "If the compiler gets a fatal signal, for
        any input whatever, that is a compiler bug", so presumably
        you'd like to hear about it.

        (I'm not sure whether ANSI specifies a limit on paren nesting
        depth; this might actually be an ice-on-illegal-code if so.  If
        there's any nesting construct without such a limit, a similar
        overflow can probably be constructed for it.)
>Fix:
        Unknown.  Limit recursion depth?  Switch to some other parser
        technology that makes it easier to handle such over-the-top
        input?

Reply via email to