On 8 Feb 2012, at 13:33, Richard Guenther wrote:
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.
There was also some discussion about reducing the amount of log-file
output (which might help too).
Did that ever get anywhere/who would be willing to decide what could
be dropped from the output?
Iain
