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
