limits-fndefn.c and timeouts

Michael Hope michael.hope at
Wed Oct 12 01:56:03 UTC 2011

On Tue, Oct 11, 2011 at 8:54 PM, Richard Sandiford
<richard.sandiford at> wrote:
> Michael Hope <michael.hope at> writes:
>> limits-fndefn.c takes an impressively long time to run.   On an idle
>> machine, -O3 -g -c takes 17:31 and -O2 -g -c takes   The test already
>> has a dg-timeout-factor of 4 giving a total timeout of 20 minutes.
>> Removing the -g brings this down to 30 s.  Keeping the -g and adding
>> -fno-var-tracking brings this down to 45 s.
>> We could bump the multiplier up to 8 but it's getting a bit
>> ridiculous.
> I agree.
>> Any thoughts?
> I remember Mark made a convincing case that these sorts of test don't
> belong in the main testsuite.  They add to people's testing time but
> (a) don't represent real testcases and (b) aren't going to be affected
> by the vast majority of patches.  And whether they pass or not depends
> as much on how much virtual memory is available as much as anything else.
> I think the idea was that they would be moved to a different testsuite
> that is only run on demand.  Then (hopefully) regular automatic testers
> like H.J.'s would run this extra testsuite too.  But I don't think a
> consensus was ever reached...

OK.  We'll check but generally accept any changes in limit test results.

Separately, does this show a performance problem with var tracking?
Turning on var tracking leads to a 20 x slow down in this particular

-- Michael

More information about the linaro-toolchain mailing list