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]