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. > On a different note, shouldn't these time out's be reported as UNRESOLVED > rather than fails? Seems like the framework isn't reporting properly. No. An infinite loop is failure. The timeouts are not supported to be close.
