This is the mail archive of the gcc@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]
Other format: [Raw text]

Re: legitimate parallel make check?


IainS <developer@sandoe-acoustics.co.uk> writes:

> ..  I don't seem to get the bus errors on a 4CPU g5 or a Core 2 duo .. but
> .. the 8-core machine is faster .. so ... race conditions are more  likely
> to manifest there.

But race conditions don't manifest themselves in make SEGVs ;-(  I'm
regularly running make -k -j128 on a T5220, or -j32 on a Sun Fire X4450
with 4 4-core CPUs, without any problems.

>> You'd still have to handle the library tests you want to run.
>
> I assume that " make -jn -k check-target RUNTESTFLAGS.... " is equally
> reasonable?

Indeed, as well as using a site.exp and pointing the DEJAGNU environment
variable at it, as I've learned from looking at the regression tester
sources in contrib/regression.  Here's what I use for that:

global target_list

case "$target_triplet" in {
    { "i?86-*-solaris2.1[0-9]" } {
	# FIXME: Disable multilib testing if the host cannot execute AMD64
	# binaries.  Should be exceedingly rare now (cf. erebus).
	set target_list { "unix{,-m64}" }
    }
    { "mips-sgi-irix6*" } {
	# FIXME: Disable multilib testing if the host cannot execute N64
	# binaries.  We cannot selectively disable only one multilib during
	# the build.
	set target_list { "unix{,-mabi=32,-mabi=64}" }
    }
    { "sparc*-*-solaris2*" } {
	set target_list { "unix{,-m64}" }
    }
    default {
	# Works for alpha*-*-osf*, i?86-*-solaris2.[89] and mips-sgi-irix5*
	# testing. 
        set target_list { "unix" }
    }
}

> I do build gmp/mpfr/mpc in-tree...
> given that I almost always run the whole testsuite - I'm torn between
> thinking it's a good idea..
> ... and that I'm essentially proving little when the versions of gmp/
> mpfr/and mpc are static.

I'd keep gmp/mpfr/mpc at a fixed version, test them once, and be done
with it.  Testing the compiler and runtime libraries on its own takes
enough time already.

> FWIW: I'm trying to update contrib/btest.sh script to handle m32 & m64 plus
> a few other things ...

No need: works already via DEJAGNU described above.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University


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