limits-fndefn.c and timeouts
michael.hope at linaro.org
Wed Oct 12 01:56:03 UTC 2011
On Tue, Oct 11, 2011 at 8:54 PM, Richard Sandiford
<richard.sandiford at linaro.org> wrote:
> Michael Hope <michael.hope at linaro.org> 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
> 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
More information about the linaro-toolchain