This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] increase timeout in simulate-thread gdb test


On Wed, Feb 8, 2012 at 2:11 PM, Andrew MacLeod <amacleod@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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]