public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: IainS <developer@sandoe-acoustics.co.uk>
To: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Cc: Janis Johnson <janis.marie.johnson@gmail.com>,
	        GCC Development <gcc@gcc.gnu.org>
Subject: Re: legitimate parallel make check?
Date: Tue, 09 Mar 2010 20:33:00 -0000	[thread overview]
Message-ID: <8062B0D2-8D60-43E2-B981-8C434F46ED05@sandoe-acoustics.co.uk> (raw)
In-Reply-To: <yddpr3dnv7o.fsf@manam.CeBiTec.Uni-Bielefeld.DE>


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

  reply	other threads:[~2010-03-09 20:33 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-09 11:43 IainS
2010-03-09 12:11 ` Rainer Orth
2010-03-09 12:29   ` IainS
2010-03-09 12:46     ` Rainer Orth
2010-03-09 15:05       ` IainS
2010-03-09 15:17         ` Rainer Orth
     [not found]           ` <fc556a771003091113g4837d6e4o9e34288d8344f2@mail.gmail.com>
2010-03-09 19:28             ` IainS
2010-03-09 19:31               ` NightStrike
2010-03-09 19:36                 ` IainS
2010-03-09 19:36               ` Rainer Orth
2010-03-09 20:33                 ` IainS [this message]
     [not found]                   ` <yddfx48o7zj.fsf@manam.CeBiTec.Uni-Bielefeld.DE>
     [not found]                     ` <AFABE34F-D88B-4C9D-BD07-0DBACCB36F64@sandoe-acoustics.co.uk>
     [not found]                       ` <yddy6i0mrsv.fsf@manam.CeBiTec.Uni-Bielefeld.DE>
2010-03-10 20:59                         ` IainS
2010-03-09 14:23     ` Tim Prince

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8062B0D2-8D60-43E2-B981-8C434F46ED05@sandoe-acoustics.co.uk \
    --to=developer@sandoe-acoustics.co.uk \
    --cc=gcc@gcc.gnu.org \
    --cc=janis.marie.johnson@gmail.com \
    --cc=ro@CeBiTec.Uni-Bielefeld.DE \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).