doc/gty.texi incomplete

[der Mouse]

In case anyone cares

The gcc version shipped with NetBSD 4.0.1 ("gcc version 4.1.2 20061021
prerelease (NetBSD nb3 20061125)") has a doc/gty.texi that is rather
incomplete.  Specifically, it lists three things that must be marked
for the garbage collector, with wording that implies the list is
exhaustive:

All @code{struct} and @code{union} declarations that define
data structures that are allocated under control of the garbage
collector must be marked.  All global variables that hold
pointers to garbage-collected memory must also be marked.
Finally, all global variables that need to be saved and
restored by a precompiled header must be marked.

However, this is incomplete.  I added a field to c_parser

  c_lcs *lcs

but did not mark anything new with GTY because c_lcs is not a
garbage-collected type.  (Whether or not this is a good design for my
purposes is irrelevant here.)

But then, upon trying to build the resulting source, gengtype fell
over, complaining "unidentified type `c_lcs'".  Obviously, there is
something else that needs marking somehow, beyond the things listed,
but it is not clear what, nor what the correct marking is.  (It's
possible that the problem is that GCed memory may not contain pointers
to non-GCed memory, but if so that needs to be clearly specified; if
it's there now, I couldn't find it.  The closest I could find was a
statement that "[t]he type machinery expects all pointers to point to
the start of an object", which the pointer I added does.)

It's possible this is NetBSD damage; their import has damaged the gcc
tree in at least one known way (BUGS has disappeared), but it seems
unlikely to me that they'd ship the doc file for a different version
from the source.  I don't see anything akin to source-code control IDs
in the files, so I'm not sure how to most usefully identify the exact
versions of individual files; if you believe this is NetBSD damage, let
me know and I'll file a NetBSD bug report for it, and if you can think
of a good way for me to identify the particular file version in
question, let me know that too and I can.

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

minor cc1 crash (SIGILL in my tests)

[der Mouse]

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 1000q >> z.c
echo 0 >> z.c
yes \) | sed -e 1000q >> 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?