Re: [RFC] Our release cycles are getting longer

[Andrew Pinski <pinskia at physics dot uc dot edu>]

> 
> 
> Wiadomo¶æ napisana w dniu 2007-01-24, o godz02:30, przez David Carlton:
> 
> > For 4, you should probably spend some time figuring out why bugs are
> > being introduced into the code in the first place.  Is test coverage
> > not good enough?

The test coverage is not good for C++ while it is great for C and most
middle-end issues.  Most of the regressions being reported are not
really in any real code but made up examples by a select few GCC 
developers.

> It's "too good" to be usable. The time required for a full test suite
> run can be measured by days not hours.

Days, only for slow machines.  For our PS3 toolchain (which is really
two sperate compilers), it takes 6 hours to run the testsuite, this
is doing one target with -fPIC.  So I don't see how you can say it
takes days.

>  The main reason is plain and
> simple the use of an inadequate build infrastructure and not the pure
> size of code compiled for coverage. Those things get completely  
> ridiculous
> for cross build targets.

No, not really, it took me a day max to get a spu-elf cross compile
building and runing with newlib and all.


> No. The problems are entierly technical in nature. It's not a pure human
> resources management issue.

Actually they are poltical reasons rather than technical.  Human resource
management is actually the biggest issue because most developers have a
day job working on GCC and not supporting the FSF mainline.

> > My favorite tactic to decrease the number of
> > bugs is to set up a unit test framework for your code base (so you can
> > test changes to individual functions without having to run the whole
> > compiler), and to strongly encourage patches to be accompanied by unit
> > tests.
> 
> That's basically a pipe dream with the autoxxxx based build system.  

Actually the issues here are unrelated at all to auto* and unit test framework.

> It's even
> not trivial to identify dead code...

It is almost hard to identify dead code in any program that has much history as GCC.  GCC
is on its 20th birthday this year.  What code out there has lasted that long and does
not have hard places to identify dead code?

> A trivial by nature change like the
> top level build of libgcc took actually years to come by.

Unrelated to any of the above issues.  Once the patch was written, there was only small
changes to the code to have toplevel libgcc work on weirder targets like Darwin or Netware.
Nothing special was needed really.  The real reason why toplevel libgcc took years to come
by is because nobody cared enough about libgcc to do any kind of clean up.  The attitude has
changed recently (when I say recent I mean the last 3-4 years) to all of these problems and
in fact all major issues with GCC's build and internals are changing for the better.

-- Pinski

PS auto* is not to blame for GCC's problems, GCC is older than auto*.