------- Comment #4 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2006-04-05 10:20 ------- Subject: Re: [4.1/4.2 Regression] 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. :/ the problem is that it is a bit hard to avoid this. What code should we produce for signed i; char *x; x + i? In order to avoid overflows when the addition is casted to an unsigned type, we would have to translate it to (i < 0) ? x - (char *) (-i) : x + (char *) i, which would be really bad. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27039
