Re: limits-fndefn.c and timeouts

2011-10-17 Thread Michael Hope
On Thu, Oct 13, 2011 at 1:03 AM, Ulrich Weigand wrote: > Michael Hope wrote: > >> Separately, does this show a performance problem with var tracking? >> Turning on var tracking leads to a 20 x slow down in this particular >> case. > > I'd agree that is a performance problem; probably some nonline

Re: limits-fndefn.c and timeouts

2011-10-12 Thread Ulrich Weigand
Michael Hope wrote: > Separately, does this show a performance problem with var tracking? > Turning on var tracking leads to a 20 x slow down in this particular > case. I'd agree that is a performance problem; probably some nonlinear behaviour in the var tracking algorithms. B.t.w. I'd say that

Re: limits-fndefn.c and timeouts

2011-10-11 Thread Michael Hope
On Tue, Oct 11, 2011 at 8:54 PM, Richard Sandiford wrote: > Michael Hope 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. >

Re: limits-fndefn.c and timeouts

2011-10-11 Thread Richard Sandiford
Michael Hope 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

limits-fndefn.c and timeouts

2011-10-10 Thread Michael Hope
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 bring