On Wed, Dec 07, 2011 at 08:09:06PM +0100, Uros Bizjak wrote:
> 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.
Any chance we can get some sort of fix into FSF gcc 4.7 for this issue?
FYI, it appears that the current setup of gcc-simulate-thread.exp doesn't honor
the use of { dg-timeout-factor 2.0 } as written. Only manually increasing the
time to 20, per the originally proposed patch, works.
Jack
