On Wed, Dec 7, 2011 at 7:58 PM, Iain Sandoe
<develo...@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.
