On Wed, Feb 8, 2012 at 2:11 PM, Andrew MacLeod <amacl...@redhat.com> 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. > > 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.
Well - it depends. You don't know whether the test will eventually terminate, but yes, you could interpret "UNRESOLVED" as exactly what that is. A definite finishes-never would be a FAIL of course. The question is on which side to err. Richard.
