This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: regression hunt status, question about reports to mailing list
- From: Wolfgang Bangerth <bangerth at ticam dot utexas dot edu>
- To: Joe Buck <jbuck at synopsys dot com>
- Cc: Janis Johnson <janis187 at us dot ibm dot com>, <gcc at gcc dot gnu dot org>, <rodrigc at attbi dot com>
- Date: Fri, 20 Dec 2002 15:15:03 -0600 (CST)
- Subject: Re: regression hunt status, question about reports to mailing list
> > It's just that I see that there are more than 1800 open bug reports (of
> > which alone 590 are for C++), and that reports are filed at a much higher
> > rate than they are fixed. Sometimes I just wished we had more focus on
> > fixing existing bugs than introducing yet another middle-end optimization.
> > But that's just my opinion.
>
> To make progress against such a huge flow of bugs, we need to prioritize
> better. A switch to Bugzilla will make this easier.
The situation is not improved by the continuing delays in introducing
Bugzilla. I am really looking forward to have it.
Two observations though:
- The fact that we have so many reports shouldn't be so surpring. It's not
as if a tidal wave is suddenly crashing onto us -- these reports have
been accumulating for a long time.
- It seems true that we have an army of people hacking on various new
optimization steps on several branches, while we have only a handful
that try to fix the existing bugs. Whether this situation changes
noticably when we have more options for prioritizing remains to be
seen, but I'm not too optimistic in this respect. (Besides: who's going
to assign priorities to 1800+ reports?)
> It's a useful service to narrow down the point where a regression appeared
> to a single patch, but it's not a guarantee that this technique will find
> a bug.
I don't think we expect that the bug will be fixed by the same person the
next day. At least I understand finding the causing patch as one way to
generate additional data points, to make searching for the real cause
simpler for those who know about the compiler. Just like stripping down a
testcase from 30,000 lines to 20.
I don't disagree with you on the relevance of knowing this patch.
Unfortunately, searching for the patches that cause a regression, and
helping to strip down testcases to a managable size is all I can do, not
knowing anything about gcc's internals.
Regards
Wolfgang
-------------------------------------------------------------------------
Wolfgang Bangerth email: bangerth@ticam.utexas.edu
www: http://www.ticam.utexas.edu/~bangerth