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
On Wed, Dec 7, 2011 at 7:58 PM, Iain Sandoe
<developer@sandoe-acoustics.co.uk> 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?
>
>
> if it's only one test can't you use { dg-timeout-factor 2.0 .... ?
>
>
>> As said elsewhere, this will double the amount of already large
>> logfile in case of failed test.
>>
>> Do we really need such detailed log?
>
>
> anything to optimize what's in the logs would be welcome in debugging
I fully agree, but it is trivial to re-run the test in the debugger
outside the testsuite run. IMO, logging a couple of lines for
execution of every instruction (in a loop!) is a bit excessive.
Uros.