From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22200 invoked by alias); 5 Apr 2006 10:28:56 -0000 Received: (qmail 22171 invoked by alias); 5 Apr 2006 10:28:54 -0000 Date: Wed, 05 Apr 2006 10:28:00 -0000 Message-ID: <20060405102854.22170.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/27039] [4.1/4.2 Regression] Unable to determine # of iterations for a simple loop In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "rguenther at suse dot de" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-04/txt/msg00411.txt.bz2 List-Id: ------- 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