regression hunt status, question about reports to mailing list

[Joe Buck]

> 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 current
definition of any regression as priority "high", even if is an ICE on
illegal code that is almost line noise (see, for example, PR 8799),
makes it too easy to generate an unlimited supply of work.  We need
to prioritize better: which bugs are likely to harm users?

+: it's a duplicate, with two or more distinct testcases
++: wrong code is generated without any warning to the user
++: test case is a correctly coded, widely used free software program
-: it's not a valid program
-: there's a simple workaround
-: an obscure corner of the language is being tested

etc.

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.  There are two possibilities: one is that the patch itself is
flawed; in such cases, if we're lucky the test case will quickly expose
what is wrong with the patch, but the issue might me more subtle.  The
other is that what we have is a "latent bug", as Kenner has often pointed
out: the patch merely perturbs something so that a bug in a completely
different part of the compiler is now triggered.  Reverting the patch
might not be a good choice, because we'd just be trading one bug for
another (the one that was fixed by the "offending" patch).  For this
reason we can't assume, just because we've isolated the apparently
offending patch, that the program can be immediately resolved.  We've
had this discussion before, and it does seem appropriate to put the
onus on a patch proposer to try to be sure that the patch is correct.
But if we find out later that there's an issue, deciding what to do is
trickier.