------- Comment #5 from rguenther at suse dot de 2010-08-27 17:23 ------- Subject: Re: Number of iteration analysis bogus
On Fri, 27 Aug 2010, rakdver at kam dot mff dot cuni dot cz wrote: > ------- Comment #4 from rakdver at kam dot mff dot cuni dot cz 2010-08-27 > 16:33 ------- > Subject: Re: New: Number of iteration > analysis bogus > > > when looking at the exit 6->7 number_of_iterations_ne is present with > > iv->base (cxb3014__test_block__char_pointers__element * {ref-all}) ref_4(D) > > and final 0B, the step is 1. We then do > > > > else > > { > > s = fold_convert (niter_type, iv->step); > > c = fold_build2 (MINUS_EXPR, niter_type, > > fold_convert (niter_type, final), > > fold_convert (niter_type, iv->base)); > > } > > > > which creates -(UNSIGNED_64) ref_4(D) for c, with no_overflow set as we > > do for pointers (but note we now have unsigned_type_for, a non-pointer!) > > This looks correct to me, as far as I can tell. The original induction > variable > has pointer type, and thus it cannot overflow without causing undefined > behavior. > > I do not understand the problem; what would you expect the result of the > analysis to be? At the moment we get (for the C testcase): Analyzing # of iterations of loop 1 exit condition [p_4(D), + , 1](no_overflow) != 0B bounds on difference of bases: -18446744073709551615 ... 0 result: # of iterations -(long unsigned int) p_4(D), bounded by 0 Statement (exit)if (p_1 == 0B) is executed at most -(long unsigned int) p_4(D) (bounded by 0) + 1 times in loop 1. thus, nb-iterations is bound by zero. But that's wrong, we're using the estimate for an exit that isn't taken (or that estimate is wrong). 0 - (UNSIGNED_64) ref_4(D) is overflowing, so we shouldn't assess that there's no overflow involved. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45427