This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: V3: SPARC bug and tree freeze


<<glibc is too big to use as a check-in criteria.  However, it should be
part of the release testing process, and nightly jobs to test
substantial programs (like glibc) are a Good Thing.
>>

Is that really true with modern fast computers. In the GNAT world, the
checkin criterion for even the tiniest "can't-possibly-affect-anything"
modification is to run the entire internal regression suite (about 7000
test cases, about 7 million lines of code). The way we do it is with
a robot that accepts the patch as a message and runs the suite 
automatically. It takes a few hours of running time on a fast machine.
Certainly testing glibc sounds like something that could be done quite
quickly.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]