Re: legitimate parallel make check?

[IainS <developer at sandoe-acoustics dot co dot uk>]

On 9 Mar 2010, at 19:36, Rainer Orth wrote:

> 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

I'm running memchecks on my 8-core machine ..

> 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" }
>    }
> }

that's really neat indeed - I should have spotted the potential  
looking at the code in contrib
...  although the site.exp is hardwired in btest.sh at present ;
 I guess one might be able to use .dejagnurc - just need to check on  
the order that the files are processed.

> > 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.

hmm.  I see that the make check would work using that neat method  
above...
... however,

1/ I want a different language list than the default...
2/ also some other different configure options...

but mainly
3/
...  As I read it -  btest.sh strips everything but the testname from  
the PASSES and FAILS files. (the awk lines that print $2 for a match  
of /FAIL: / etc.)
This means (e.g.) that if a test passes at m32 and fails at m64 I  
think it will appear in both PASSES and FAILS..
...  this seems destined to result in confusion...

I would like to  identify regressions separately for m32 and m64 -  
esp. in obj-c/c++ where there are huge differences on NeXT runtime  
systems.

if I've missed the blindingly obvious (the day job is taking up most  
of my mental resources ;-)) please point it out :-)

Iain