------- Comment #3 from rguenther at suse dot de 2006-04-05 10:13 ------- Subject: Re: [4.1/4.2 Regression] Unable to determine # of iterations for a simple loop
On Wed, 5 Apr 2006, rakdver at atrey dot karlin dot mff dot cuni dot cz wrote: > Subject: Re: Unable to determine # of iterations for a simple loop > > > Confirmed. That gives us a testcase at least. > > > > Now, back to the folding problem of > > > > PTR +- CST CMP PTR +- CST > > > > where all of PTR / CST are of pointer type naturally and unsigned usually. > > The problem was that the frontends/middle-end introduce pointer overflow via > > presenting us with PTR + (unsigned)-CST. Now, we may argue that if > > (signed)CST > > is positive, that this didn't happen, and we can do the comparison in either > > signed or unsigned mode. > > If p points to the end of the array whose size is more than range of > signed, then this would make you mistakenly consider p - size > p. Umm. Correct :/ I guess the only way to "fix" the mess is to make the frontends _not_ generate these spurious pointer overflows in the first place. Like I asked for in http://gcc.gnu.org/ml/gcc/2006-03/msg00866.html where nobody commented. :/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27039
