Re: GCC 4.2.0 Status Report (2007-04-15)

["Steven Bosscher" <stevenb dot gcc at gmail dot com>]

On 4/16/07, Mark Mitchell <mark@codesourcery.com> wrote:
> 29841  [4.2/4.3 regression] ICE with scheduling and __builtin_trap

Honza, PING!

> 31360  [4.2/4.3 Regression] rtl loop invariant is broken

Zdenek, PING!

> The broader question of why there are so many 124 P3 or higher
> regressions against 4.2.0 points to a more fundamental problem.

Quick bug breakdown:

46 c++ bugs:
   13 of these are assigned

33 missed-optimizations:
   7 of these are assigned

So that's 79 of 124 bugs, almost two thirds of all bugs.

Only 6 of the 124 bugs are reported against a compiler older than gcc
4.0, so most of these regressions are fairly recent.

Only 29 of 124 bugs are assigned to a developer, but some bugs have
been assigned since forever to the assignee without any sign progress
towards a fix, ever. So in reality, even fewer than 29 bugs have an
active assignee.  That's less than one fourth of all "serious
regressions" being taken seriously.

Then again, all things considering it seems to me that having 33
missed optimizations as regressions only makes things look terribly
bad, while in reality the situation is really not so bad at all. The
usual discussion about bikeshed regressions vs. real significant
progress: With 33 missed optimizations, GCC 4.2 still produces
measurably better scores on the usual benchmarks.

So maybe the fundamental problem is that we just have bugs that look
more serious than they really are. Certainly some of the missed
optimizations are pretty severe, but the majority of these reports is
just silly.


> Despite the fact that virtually all of the bugs open against 4.2.0 are
> also open against 4.1 or 4.3 -- or both! -- there seems to be little
> interest in fixing them.

Interest in fixing regression typically peaks in the days after the
Release Manager posts a bug overview / release status. We haven't had
very many updates for this release... ;-)


> Some have suggested that I try to solve this by closing GCC 4.3
> development until 4.2.0 is done.  I've considered that, but I don't
> think it's a good idea.  In practice, this whole software freedom thing
> means that people can go off and do things on their own anyhow; people
> who are more motivated to add features than fix bugs are likely just to
> keep doing that, and wait for mainline to reopen.

I think that, as the Release Manager, you should just near-spam the
list to death with weekly updates, and keep pushing people to fix
bugs. I think most of the time, people don't fix their bugs simply
because they're too involved with the fun stuff to even think about
fixing bugs. That's how it works for me, at least.

I think the release manager should try to get people to do the hard
work of identifying the cause of bugs, which is usually not really
hard at all.  For example:

* Janis has more than once been asked to reghunt a regression, and
she's always been very helpful and quick to respond, in my experience.

* Very few people know how to use Janis' scripts, so to encourage
people to use them, the release manager could write a wiki page with a
HOWTO for these scripts (or ask someone to do it).  Regression hunting
should only be easier now, with SVN's atomic commits. But the easier
and more accessible you make it for people to use the available tools,
the harder it gets for people to justify ignoring their bugs to "the
rest of us".

* Maintainers of certain areas of the compiler may not be sufficiently
aware of some bug in their part of the compiler. For example, only one
of the three preprocessor bugs is assigned to a preprocessor
maintainer, even though in all three preprocessor bugs a maintainer is
in the CC. It's just that the bugs have been inactive for some time.
(And in this particular case of preprocessor bugs, it's not even been
established whether PR30805 is a bug at all, but it is marked as a P2
"regression" anyway)

In summary, I just strongly encourage a more active release manager...

As of course you understand, this is intended as constructive criticism.

Gr.
Steven