This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] increase timeout in simulate-thread gdb test
On 8 Feb 2012, at 13:33, Richard Guenther wrote:
On Wed, Feb 8, 2012 at 2:11 PM, Andrew MacLeod <firstname.lastname@example.org>
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
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O2 -g thread
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O3 -g thread
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -Os -g thread
on x86_64-apple-darwin11 due to the 10 second timeout in simulate-
gcc/testsuite/lib/gcc-simulate-thread.exp. Increasing this
timeout to 20
eliminates the failures (as these test take ~16 seconds on
Okay for gcc trunk?
Ok. Ok for 4.7.
And I just recently noticed armv7 was failing *all* the simulate-
tests for the same reason. 20 seconds appears to make it pass all
there as well.
On a different note, shouldn't these time out's be reported as
rather than fails? Seems like the framework isn't reporting
Well - it depends. You don't know whether the test will eventually
but yes, you could interpret "UNRESOLVED" as exactly what that is. A
definite finishes-never would be a FAIL of course. The question is
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?