From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17612 invoked by alias); 15 May 2009 15:45:08 -0000 Received: (qmail 17401 invoked by alias); 15 May 2009 15:44:49 -0000 Date: Fri, 15 May 2009 15:45:00 -0000 Message-ID: <20090515154449.17400.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/40087] [4.3/4.4/4.5 Regression] Number of iterations analysis wrong In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "rakdver at kam dot mff dot cuni dot cz" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-05/txt/msg01344.txt.bz2 ------- Comment #8 from rakdver at kam dot mff dot cuni dot cz 2009-05-15 15:44 ------- Subject: Re: [4.3/4.4/4.5 Regression] Number of iterations analysis wrong > > > It is number of iteration analysis that gets it wrong (I suppose it might get > > > confused by the two exits of the loop?). > > > > Sort of; # of iterations analysis assumes that pointers never wrap, and uses > > this assumption to derive a wrong number of iterations for the first exit > > (which is not taken). We had a similar problem before (PR 25985), but I > > somehow persuaded myself that this cannot happen with pointers. > > Ah - it indeed cannot happen, but you need to assume that the offsets > in POINTER_PLUS_EXPRs are signed (even though they are unsigned as > they are of type sizetype). that is not the problem. The problem is that # of iterations analysis has a look at the first test, of form [x,+,4] == [x + 28, +, -4], observes that the variables do not wrap, and concludes that the loop is not infinite. So far OK, but next we infer that this means that the exit is taken, i.e., that 28 % 8 = 0, and the things go down for there. I fixed this error before, but special-cased the pointer ivs in a strike of wishful thinking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40087