This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] increase timeout in simulate-thread gdb test
- From: Mike Stump <mikestump at comcast dot net>
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: Jack Howarth <howarth at bromo dot med dot uc dot edu>, gcc-patches at gcc dot gnu dot org, ubizjak at gmail dot com
- Date: Wed, 8 Feb 2012 13:22:08 -0800
- Subject: Re: [PATCH] increase timeout in simulate-thread gdb test
- References: <20111207184343.GA2527@bromo.med.uc.edu> <4F75A7C6-A179-48A5-9911-7C3107466634@comcast.net> <4F32747D.9010308@redhat.com>
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.