This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]