Re: [PATCH] increase timeout in simulate-thread gdb test

[Andrew MacLeod <amacleod at redhat dot com>]

On 02/08/2012 04:22 PM, Mike Stump wrote:
> On Feb 8, 2012, at 5:11 AM, Andrew MacLeod wrote:
> > On 02/07/2012 07:55 PM, Mike Stump wrote:
> > > On Dec 7, 2011, at 10:43 AM, Jack Howarth wrote:
> > > > Currently we are failing...
> > > >
> > > > FAIL: gcc.dg/simulate-thread/atomic-load-int128.c  -O1 -g  thread simulation test
> > > > FAIL: gcc.dg/simulate-thread/atomic-load-int128.c  -O2 -g  thread simulation test
> > > > FAIL: gcc.dg/simulate-thread/atomic-load-int128.c  -O3 -g  thread simulation test
> > > > FAIL: gcc.dg/simulate-thread/atomic-load-int128.c  -Os -g  thread simulation test
> > > >
> > > > on x86_64-apple-darwin11 due to the 10 second timeout in simulate-thread of
> > > > gcc/testsuite/lib/gcc-simulate-thread.exp. Increasing this timeout to 20 seconds
> > > > eliminates the failures (as these test take ~16 seconds on x86_64-apple-darwin11).
> > > > Okay for gcc trunk?
> > > Ok.  Ok for 4.7.
> > And I just recently noticed armv7 was failing *all* the simulate-thread tests for the same reason.  20 seconds appears to make it pass all tests there as well.
> In the context of recent, reasonably fast machine, no timeout should be within 10x of failing because of the timeout.  Having a 20 second timeout, when 18 are required, means failures, if you merely have 2 test suites running at the same time.  If it takes 18 seconds, the timeout should be 180 seconds, minimum.  :-(  I'd welcome a simulate threads person re-engineering what the numbers should be.
well, originally there wasn't a special number.  Someone added the 10 
seconds because most of the testcases are short, and they generated  a 
*lot* of log. If an infinite loop did happen (which it did), the 300 
second timeout could generate a huge log file that fills the 
filesystem.  I think there was a defect for that...  Anyway, I think 10 
seconds just came out of someones imagination, but I'm not sure.  Was 
that you Aldy?

Given thats the case, I'd be more tempted long term to simply disable 
the line by line output into the log file...  I assume thats possible. 
then we dont need any special time outs.  If a failure needs 
investigation, you look at it by hand.

Andrew