GCC Status (2004-08-09)

[Joseph S. Myers]

On Wed, 11 Aug 2004, Mark Mitchell wrote:

> > I would suggest that if we're going to go into stage 3, but still
> > allow patches for compile speed, code quality, and bug fixing, we
> > might as well call it stage 2.
> >  
> Problems with compile speed and code quality are bugs.

They are also generally regressions in the cases we particularly care 
about (for compile speed, regressions since some sufficiently old and fast 
release, if not since the last release).  But I use a very general 
definition of regressions 
<http://gcc.gnu.org/ml/gcc/2004-06/msg01288.html> such that we can't 
feasibly keep to having no regressions, though we should be as close as we 
can while still getting releases out in reasonable time.

(Although with such a wide definition of regressions, for many obscure 
bugs I can contrive testcases which show by some interaction of changes to 
the compiler a particular bug is a regression because a contrived case 
worked by accident in a previous version, I don't then press such cases as 
being regressions it's worthwhile fixing in previous release branches.)

I have no magic solution to the growth of regressions during development.  
The technical problem of swiftly ascribing most identified regressions to 
the exact commits that caused them is solvable (where single commits 
rather than gradual changes caused regressions, which isn't the case with 
many performance changes).  The problem that some contributors may not 
find it interesting or rewarding to fix bugs or may find adding features 
preferable to ensuring the compiler works really well is harder, and going 
to Stage 3 only has a limited effect insofar as some development effort 
just gets directed away from CVS mainline.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)