This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Status of mainline (3.3) high-priority bugs
- From: Nathanael Nerode <neroden at twcny dot rr dot com>
- To: gcc-patches at gcc dot gnu dot org
- Date: Tue, 26 Nov 2002 12:58:32 -0500
- Subject: Status of mainline (3.3) high-priority bugs
There are 54 open high-priority bugs. Sounds like a lot. I'm going
to try to suggest some triage here, in the hopes of getting 3.3 out
before 3.4 is due. :-/
First of all, nearly all the bugs are either specific to compiling C++,
or to building the C++ front end. Given the state of C++ I suspect
lower standards will have to continue for it than for everything else.
They deserve their own analysis, which I won't do here.
ICEs on illegal code are bad, but I don't think they're that important,
so I've left them out of this list.
This leaves the following 12 bugs: 1 ready to be fixed, 7 I think are
important to get, 4 I think can likely wait.
c/8387: This is documentation, with a patch waiting. Can someone please
approve it already? Actually, it's all docs and comments; can it simply
be committed?
c/6815: Nasty ICE with longjmp. We should try to get this one.
c/7928: Spurious external references generated, causing link failure.
This is bad. It looks like nobody's followed up on this one. I think
we should try to get this one. May be Solaris-specific.
c/8032: Bad initialization in a funny case. Being worked on. I think
we should get this one before 3.3.
middle-end/7796: Another one that looks bad. Why is GCC ICEing on a
test case? Solaris-specific.
optimization/8492: Infinite compile time on fairly simple loop. We
should fix this.
target/7794: solaris2.7 RTL checking failures. I have to wonder if this
is related to some of the other Solaris bugs, though it seems unlikely.
Probably worth fixing before 3.3.
target/8343: Nasty ICE for m68k-elf/rtems. We probably need to fix this
-- if we can track it down, that is.
c/7227: Bogus warning; probably not worth focusing on.
c/7622: ICE on legal code, but in a weird case, dependent on nested
functions. Probably not worth focusing on. Is this present in 3.3
anyway?
optimization/2001: GCSE takes too long with computed gotos. This is one
of a class of bugs where general algorithms work well for many types of
code and badly for computed goto code. (Perhaps a note about this
general issue should be added to the guidelines for writing new
optimizations?) This might be too hard to fix for 3.3 however.
optimization/8555: Doesn't affect mainline.