public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@codesourcery.com>
To: Uros Bizjak <ubizjak@gmail.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	Adhemerval Zanella	<azanella@linux.vnet.ibm.com>
Subject: Re: [PATCH] PowerPC: Implement TARGET_ATOMIC_ASSIGN_EXPAND_FENV
Date: Thu, 04 Sep 2014 17:39:00 -0000	[thread overview]
Message-ID: <alpine.DEB.1.10.1409041824170.27075@tp.orcam.me.uk> (raw)
In-Reply-To: <CAFULd4YFTWPrC8Gbr9AHewzpXiGGGHOjOXMv+a9B_yOO8SgJYg@mail.gmail.com>

On Wed, 3 Sep 2014, Uros Bizjak wrote:

> >  So I think the default timeout that's used for really quick tests should
> > be extended a bit.  I propose a factor of 2, just not to make it too
> > excessive, at least for the beginning (maybe it'll have to be higher
> > eventually).
> 
> Or you can just lower the iteration count as I have to do for alpha.

 Thanks for the tip.

 Hmm, frankly I think setting the timeout factor has a greater chance to 
be maintenance free (no need to add further targets as they get 
discovered) and I think a bit more flexible too.  E.g. someone may (and 
often will, if they care about their test run times) override the global 
board timeout to say 5 from the default of 300 seconds in their board 
description file for their super-fast test system and the timeout factor 
will still do its work here.  Whereas with the default timeout applying 
here the lowest timeout setting that works here will be the global lower 
limit, also for tests that are inherently faster than this one (i.e. don't 
loop over thousands of iterations or in fact have no loop at all and just 
execute in a fall-through manner) even on systems where lock contention is 
not an issue.

 If you think that extending the timeout for everyone is too big a hammer 
here, then perhaps we could conditionalise it on 
target_has_contentious_atomics or suchlike and list the right targets 
there, but frankly I think it would be a bit of an overkill (and my 
observation above about looped vs non-looped tests still applies).

 Thoughts?

  Maciej

  reply	other threads:[~2014-09-04 17:39 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-03 14:08 Uros Bizjak
2014-09-04 17:39 ` Maciej W. Rozycki [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-09-16 21:05 David Edelsohn
2014-07-16 20:33 David Edelsohn
2014-08-01  3:28 ` David Edelsohn
2014-08-01 15:31   ` Joseph S. Myers
2014-08-06 20:21     ` Adhemerval Zanella
2014-08-19 16:54       ` Adhemerval Zanella
2014-09-02 22:23         ` Adhemerval Zanella
2014-09-03 14:01           ` Maciej W. Rozycki
2014-09-03 15:49             ` Joseph S. Myers
2014-09-04 18:40             ` Adhemerval Zanella
2014-09-15 14:38               ` Maciej W. Rozycki
2014-07-03 21:09 Adhemerval Zanella
2014-07-16 18:41 ` Adhemerval Zanella
2014-07-31  1:43 ` Joseph S. Myers

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=alpine.DEB.1.10.1409041824170.27075@tp.orcam.me.uk \
    --to=macro@codesourcery.com \
    --cc=azanella@linux.vnet.ibm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=ubizjak@gmail.com \
    /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).