Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug
Bug#: 10171
Product:  
Component:  
Status: RESOLVED
Resolution: FIXED
Assigned To: Jason Merrill <jason@gcc.gnu.org>
Host:
Reported against  
Priority:  
Severity:  
Target Milestone:  
 
 
Target:
Reporter: mchen@vmware.com
Add CC:
CC:
Remove selected CCs
Build:
URL:
Summary:
Keywords:
Known to work:
Known to fail:

Attachment Description Type Created Size Actions
bug.c bug.c application/octet-stream 2003-05-21 15:17 155 bytes Edit
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 10171 depends on: Show dependency tree
Show dependency graph
Bug 10171 blocks:

Additional Comments:






View Bug Activity   |   Format For Printing   |   Clone This Bug


Description:   Last confirmed: Opened: 2003-03-20 18:46
Compile the code using "gcc -O2" and the program doesn't give any output. It
works with "gcc -O1" and works with gcc 2.95.

Release:
2.96 - 3.2

Environment:
x86 Linux

How-To-Repeat:
compile using "gcc -O2" and run it

------- Comment #1 From Wolfgang Bangerth 2003-03-20 19:09 -------
State-Changed-From-To: open->analyzed
State-Changed-Why: Confirmed. Here's the same program, slightly modified:
    ------------------------
    inline int tag() { return 0; }
    
    int main() {
       int i;
       for (i = 0; i < (tag() ? 2 : 1); i++)
         printf("Hello1\n");
    }
    --------------------------
    The loop should be executed at least once, but isn't when
    compiled with -O2 on 3.2, 3.3 and mainline. It worked with
    2.95, though, so this is a regression. A serious one, I'd
    say.
    
    W.

------- Comment #2 From Jason Merrill 2003-03-21 06:10 -------
State-Changed-From-To: analyzed->open
State-Changed-Why: x

------- Comment #3 From Jason Merrill 2003-03-21 06:17 -------
State-Changed-From-To: open->analyzed
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.

------- Comment #4 From Jason Merrill 2003-03-21 18:45 -------
From: Jason Merrill <jason@redhat.com>
To: Steven Bosscher <s.bosscher@student.tudelft.nl>
Cc: gcc-gnats@gcc.gnu.org, mchen@vmware.com, gcc-bugs@gcc.gnu.org,
   nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org, agesen@vmware.com,
   mendel@vmware.com
Subject: Re: optimization/10171: [3.2/3.3/3.4 regression] wrong code for
 inlined function
Date: Fri, 21 Mar 2003 18:45:52 -0500

 On Sat, 22 Mar 2003 00:33:02 +0100, Steven Bosscher <s.bosscher@student.tudelft.nl> wrote:
 
 >  From your analysis, I would suspect that this PR is a duplicate
 > of high-priority PR opt/8414. Is there any way to verify this?
 
 I don't think so; it doesn't look like the loop in 8414 only has a single
 iteration.
 
 Jason


------- Comment #5 From s.bosscher@student.tudelft.nl 2003-03-22 00:33 -------
From: Steven Bosscher <s.bosscher@student.tudelft.nl>
To: gcc-gnats@gcc.gnu.org, mchen@vmware.com, gcc-bugs@gcc.gnu.org,
	nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org, agesen@vmware.com,
	mendel@vmware.com, jason@gcc.gnu.org
Cc:  
Subject: Re: optimization/10171: [3.2/3.3/3.4 regression] wrong code for inlined
 function
Date: Sat, 22 Mar 2003 00:33:02 +0100

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10171
 
 Jason,
 
  From your analysis, I would suspect that this PR is a duplicate
 of high-priority PR opt/8414. Is there any way to verify this?
 
 (Hoping you *do* have access to IA64 hardware ;-)
 
 Greetz
 Steven
 
 


------- Comment #6 From janis187@us.ibm.com 2003-03-22 13:40 -------
From: Janis Johnson <janis187@us.ibm.com>
To: gcc-gnats@gcc.gnu.org, mchen@vmware.com, gcc-bugs@gcc.gnu.org,
   nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org, agesen@vmware.com,
   mendel@vmware.com
Cc:  
Subject: Re: optimization/10171: [3.2/3.3/3.4 regression] wrong code for inlined 
 function
Date: Sat, 22 Mar 2003 13:40:07 -0800

 Not that it's useful, but for i686-linux the regression
 appears with this patch:
 
 Wed Sep  1 21:13:48 1999  Richard Henderson  <rth@cygnus.com>
 
         Merge new ia32 backend from the branch!
 
         * i386.h, i386.c, i386.md, reg-stack.c, i386/unix.h: Many
 changes.
         See ChangeLog.P2 on new_ia32_branch for details.
 
         * rtl.h (stack_regs_mentioned_p): Delete prototype.
         * i386/cygwin.h (SUBTARGET_PROLOGUE): No more do_rtl.
         * i386/win32.h (SUBTARGET_PROLOGUE): Likewise.
         * i386/gas.h (ASM_FILE_START): Define.
         * i386/winnt.c (i386_pe_valid_decl_attribute_p): Update
         for name change of ix86_valid_decl_attribute_p.
         (i386_pe_valid_type_attribute_p): Similarly.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10171
 
 
 


------- Comment #7 From janis187@us.ibm.com 2003-03-22 15:01 -------
From: Janis Johnson <janis187@us.ibm.com>
To: Steven Bosscher <s.bosscher@student.tudelft.nl>
Cc: gcc-gnats@gcc.gnu.org, mchen@vmware.com, gcc-bugs@gcc.gnu.org,
   nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org, agesen@vmware.com,
   mendel@vmware.com, janis187@us.ibm.com
Subject: Re: optimization/10171: [3.2/3.3/3.4 regression] wrong code for inlined function
Date: Sat, 22 Mar 2003 15:01:50 -0800

 On Sat, Mar 22, 2003 at 11:22:32PM +0100, Steven Bosscher wrote:
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10171
 > 
 > Janis,
 > 
 > If the patch you identified really breaks stuff, then this PR should be 
 > in the
 > category "target", agree?
 
 Not necessarily; see Jason's comment about how -O2 does some unrolling.
 The identified patch might have merely made that change (as far as this
 problem is concerned).


------- Comment #8 From s.bosscher@student.tudelft.nl 2003-03-22 23:22 -------
From: Steven Bosscher <s.bosscher@student.tudelft.nl>
To: gcc-gnats@gcc.gnu.org, mchen@vmware.com, gcc-bugs@gcc.gnu.org,
	nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org, agesen@vmware.com,
	mendel@vmware.com, janis187@us.ibm.com
Cc:  
Subject: Re: optimization/10171: [3.2/3.3/3.4 regression] wrong code for inlined
 function
Date: Sat, 22 Mar 2003 23:22:32 +0100

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10171
 
 Janis,
 
 If the patch you identified really breaks stuff, then this PR should be 
 in the
 category "target", agree?
 
 Greetz
 Steven
 
 


------- Comment #9 From Jason Merrill 2003-03-25 20:23 -------
From: jason@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: optimization/10171
Date: 25 Mar 2003 20:23:08 -0000

 CVSROOT:	/cvs/gcc
 Module name:	gcc
 Branch: 	gcc-3_3-branch
 Changes by:	jason@gcc.gnu.org	2003-03-25 20:23:08
 
 Modified files:
 	gcc            : ChangeLog unroll.c 
 
 Log message:
 	PR optimization/10171
 	* unroll.c (unroll_loop): Don't delete the jump at the end unless
 	we also delete a jump at the beginning.
 
 Patches:
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.16114.2.362&r2=1.16114.2.363
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/unroll.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.184.2.1&r2=1.184.2.2
 


------- Comment #10 From Jason Merrill 2003-03-25 20:23 -------
From: jason@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: optimization/10171
Date: 25 Mar 2003 20:23:28 -0000

 CVSROOT:	/cvs/gcc
 Module name:	gcc
 Branch: 	gcc-3_2-branch
 Changes by:	jason@gcc.gnu.org	2003-03-25 20:23:28
 
 Modified files:
 	gcc            : ChangeLog unroll.c 
 
 Log message:
 	PR optimization/10171
 	* unroll.c (unroll_loop): Don't delete the jump at the end unless
 	we also delete a jump at the beginning.
 
 Patches:
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_2-branch&r1=1.13152.2.657.2.279&r2=1.13152.2.657.2.280
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/unroll.c.diff?cvsroot=gcc&only_with_tag=gcc-3_2-branch&r1=1.160.2.4.2.4&r2=1.160.2.4.2.5
 


------- Comment #11 From Jason Merrill 2003-03-25 20:24 -------
From: jason@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: optimization/10171
Date: 25 Mar 2003 20:24:26 -0000

 CVSROOT:	/cvs/gcc
 Module name:	gcc
 Changes by:	jason@gcc.gnu.org	2003-03-25 20:24:26
 
 Modified files:
 	gcc            : ChangeLog unroll.c 
 
 Log message:
 	PR optimization/10171
 	* unroll.c (unroll_loop): Don't delete the jump at the end unless
 	we also delete a jump at the beginning.
 
 Patches:
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=1.17214&r2=1.17215
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/unroll.c.diff?cvsroot=gcc&r1=1.189&r2=1.190
 


------- Comment #12 From Jason Merrill 2003-03-25 20:24 -------
From: jason@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: optimization/10171
Date: 25 Mar 2003 20:24:42 -0000

 CVSROOT:	/cvs/gcc
 Module name:	gcc
 Changes by:	jason@gcc.gnu.org	2003-03-25 20:24:42
 
 Added files:
 	gcc/testsuite/gcc.dg: loop-2.c 
 
 Log message:
 	PR optimization/10171
 	* unroll.c (unroll_loop): Don't delete the jump at the end unless
 	we also delete a jump at the beginning.
 
 Patches:
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/loop-2.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
 

------- Comment #13 From Jason Merrill 2003-03-25 20:36 -------
Responsible-Changed-From-To: unassigned->jason
Responsible-Changed-Why: x

------- Comment #14 From Jason Merrill 2003-03-25 20:36 -------
State-Changed-From-To: analyzed->closed
State-Changed-Why: fixed

Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug