On Sat, 21 Jun 2008, Andrew Haley wrote:

> Steven Bosscher wrote:
> > On Sat, Jun 21, 2008 at 12:41 AM, Kaveh R. Ghazi <[EMAIL PROTECTED]> wrote:
> >> Fundamentally, our philosophy has been to catch errors *before* they get
> >> into the repository.  Sure one day of breaking the trunk isn't so bad, but
> >> when it breaks it affects hundreds of developers and it adds up.
> >
> > But, for languages that are not enabled by default, no-one is directly
> > affected except the people who might have caused the breakage, and the
> > people who are working on the broken part of the compiler.
>
> They are directly affected by these errors, but they don't know: the 
> middle-end
> bugs revealed by the libjava build and testing are real bugs in other 
> languages
> too, they're just not detected by bootstrap & test.
> Andrew.
Andrew,

I think you hit the heart of this argument.  The current bootstrap and
testsuite doesn't ensure complete code coverage testing for GCC.  Having
more languages, libraries and their associated testsuites uncovers more
bugs that would otherwise go undetected and remain hidden in the core
middle-end.

These hidden bugs could possible be triggered in C, C++ and/or fortran,
but our current testsuite may not trigger them by chance whereas java or
objc++ or whatever else we include might expose them during bootstrap.

The argument for switching off java (that it takes too long) could be
applied to C++ as well.  The libstdc++ testsuite takes longer for me than
the java one.  But I don't recommend eliminating that either.  How
widespread a language is used is not the determining factor in whether we
should activate it by default.  Many people have vouched for the fact that
java exposes middle-end bugs not uncovered by the other languages.  That
is where the worth of including it is found.

IMHO, having more languages and testsuites in the bootstrap process
enhances the quality of GCC.  I sympathize with the problems of regtest
duration.  I believe some of this could be addressed through making things
run in parallel better.

                --Kaveh
--
Kaveh R. Ghazi                  [EMAIL PROTECTED]

Reply via email to