This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Small update to reversed_comparison_code
- To: Daniel Berlin <dberlin at redhat dot com>
- Subject: Re: Small update to reversed_comparison_code
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Date: Wed, 14 Mar 2001 08:29:14 +0000 (GMT)
- cc: Mark Mitchell <mark at codesourcery dot com>, <gcc at gcc dot gnu dot org>, <dewar at gnat dot com>
On 14 Mar 2001, Daniel Berlin wrote:
> GCCTesting@Home.
>
> Funny, but if you had people with spare cycles on enough target
> machine types, it would work. This is assuming the problem is getting
> one of every machine. I'm willing to bet at least one random gcc user
> for each platform would let you do it, if it only required say 100
> meg, and a client they had to download.
> The real problem here is that it's a serious pain in the ass to do the
> testing, and users don't like serious pain in the asses.
We already have people reporting results to gcc-testresults (and even a
testresults database) but interpreting the data there can be difficult,
some results can depend on the rest of one's system environment, some
testcases give bogus failures depending on (it seems) the testsuite
framework versions, and so on. This gives a rough idea - someone could
attempt to rig up a regression detector connected to it - but for reliable
warnings about regressions, the machines in question need to have
well-controlled environments, which don't give spurious test failures.
If you want to make the submission of results to gcc-testresults easier,
that would be a good idea - for example, testing of bootstraps with random
strange CFLAGS is a good candidate for using many machines.
Building and testing GCC also uses a lot of memory at times.
--
Joseph S. Myers
jsm28@cam.ac.uk