On 9 Mar 2010, at 19:36, Rainer Orth wrote:
IainS <develo...@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
