From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27474 invoked by alias); 21 Mar 2003 06:17:28 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 27453 invoked by uid 48); 21 Mar 2003 06:17:28 -0000 Date: Fri, 21 Mar 2003 06:17:00 -0000 Message-ID: <20030321061728.27452.qmail@sources.redhat.com> To: agesen@vmware.com, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, mchen@vmware.com, mendel@vmware.com, nobody@gcc.gnu.org From: jason@gcc.gnu.org Reply-To: jason@gcc.gnu.org, agesen@vmware.com, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, mchen@vmware.com, mendel@vmware.com, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org Subject: Re: optimization/10171: [3.2/3.3/3.4 regression] wrong code for inlined function X-SW-Source: 2003-03/txt/msg01374.txt.bz2 List-Id: Synopsis: [3.2/3.3/3.4 regression] wrong code for inlined function State-Changed-From-To: open->analyzed State-Changed-By: jason State-Changed-When: Fri Mar 21 06:17:28 2003 State-Changed-Why: This is a bug in loop unrolling; 2.95 shows the bug with -funroll-loops. The only difference is that now we do some unrolling at -O2. The loop optimizer properly calculates that there will always be a single pass through the loop. The unroller has a special case for this. It looks for and deletes an unconditional jump to the continue point, then deletes a conditional jump from the end of the loop. Unfortunately, this code fails to handle nontrivial for loops, as the unconditional jump at the beginning of the loop (created previously by loop inversion) is to the test, not to the continue point. So that jump is not deleted, but the conditional jump at the end is, and so we just skip over the loop. Oops. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10171