This is the mail archive of the
mailing list for the GCC project.
Re: Moving towards GCC 3.1
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: rth at redhat dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 26 Dec 01 15:20:37 EST
- Subject: Re: Moving towards GCC 3.1
> (3) Fixing latent bugs
Not granted as a separate category. If it's a latent bug, then
it must fall into 1 or 2, or have a new test case.
By "latent", I mean a bug that is observed by reading code (or while
searching for a bug which was elsewhere) but which cannot at present
cause problems because something else (perhaps another bug) prevents
it from being relevant. For example, it would occur only on a target
machine with two values of macros and we don't have any such, at present.
This sort of bug is a timebomb and should be fixed as soon as it is
discovered, but, by definition you can't come up with a test case for it.
Define "code quality issues".
Code that doesn't meet the coding standards, is inadequately documented,
is unclear, or similar. Part of getting ready for a release is to make
a pass over files and ensure we are meeting our documentation and
coding standards. I've gone through nine files and fixed what I could (but
I can't add missing documentation), but others needs to pick up the ball
with the rest of the files and fill in the missing documentation for those.
It's funny, because I work with proprietary test suites all the time,
and about 2/3 of the time I manage to generate an independant test
case from problems seen there. More if you discount reload problems.
My experience is a lower number, which may be due to differences
between typical C and Ada programs, but whatever the number, I don't
think we want to say that only the ones where test cases can be generated
should be fixed during this development phase.