------- Comment #5 from rguenther at suse dot de 2006-04-05 10:28 ------- 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: > > 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. At the moment the C frontend does in the x + i case x + (char *)(size_t)i so, now this would be problematic for x + i < x which would then become (effectively) (size_t)i < 0 which is false even for negative i. Now, the frontend makes it worse, because for constant offsets I believe we _can_ fold if we know the constant didn't overflow. I.e. at the moment for x - 1 we get x + (char *)(size_t)-1 which is bad, instead x - (char *)(size_t)1 would be much better here. The question is of course, if the programmer is allowed to write x + (size_t)-1 and expect the result to be defined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27039
