Bug 17860 - [3.4 only] Wrong generated code for loop with varying bound
Summary: [3.4 only] Wrong generated code for loop with varying bound
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 3.4.2
: P2 normal
Target Milestone: 3.4.5
Assignee: Paolo Bonzini
URL:
Keywords: monitored, patch, wrong-code
: 17861 (view as bug list)
Depends on:
Blocks: 21015
  Show dependency treegraph
 
Reported: 2004-10-06 12:50 UTC by tal agmon
Modified: 2005-08-09 08:23 UTC (History)
7 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work: 4.0.0
Known to fail: 2.95.3 3.3.2 3.4.2 3.4.3
Last reconfirmed: 2005-02-26 18:42:42


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tal agmon 2004-10-06 12:50:56 UTC
Compile the following code with: gcc -O3. The output should be 

   foo is: 0, i is: 1

Yet the output is:

   foo is: 0, i is: 0

This is the source code:

#include <stdio.h>
int foo=100;

int f ()
{
  foo = 0;
}

void main ()
{
  int i;

  for (i = 0; i < foo; i++)
    {
      f ();
    }
  printf("foo is: %d, i is: %d\n",foo,i);
}
Comment 1 Andrew Pinski 2004-10-06 12:55:08 UTC
Since this is not a regression closing as fixed for 4.0.0.
Comment 2 Andrew Pinski 2004-10-06 13:06:57 UTC
*** Bug 17861 has been marked as a duplicate of this bug. ***
Comment 3 Richard Biener 2004-10-06 13:15:20 UTC
Proper testcase:

extern void abort();
int foo=100;
inline int f ()
{
 foo = 0;
}
void main ()
{
 int i;
 for (i = 0; i < foo; i++)
     f ();
 if (i != 1)
   abort();
}

Also the rtl-optimization bug may be latent on mainline, how do we know?
Comment 4 Paolo Bonzini 2004-10-06 17:04:37 UTC
It is not fixed.  You can mark it as WONTFIX, but it is not reasonable to mark
it as FIXED.

I tried looking at some dumps for this test case, which is even more severe:

  extern void abort ();

  int
  main ()
  {
    int i;
    int foo = 2;
    for (i = 0; i < foo; i++)
      foo = 0;

    if (i != 1)
      abort ();
  }

If the alias1 pass, which cannot be disabled, wouldn't rewrite "i < foo" to "foo
> i", chances are the test case would still trigger.  I'm preparing a patch to
provide -fno-tree-ssa again, hoping that this will make more 3.4 test cases fail
again with 4.0 (GIMPLE would change the input to the RTL optimzation passes a
lot, but hopefully CSE will make things saner again).

Reopening with a target milestone of 3.4.4.

Paolo
Comment 5 Andrew Pinski 2004-10-06 17:09:11 UTC
Since this is not a regression we should not have the target milestone set, also the old loop invariant 
moving is being removed the last time I heard.
Comment 6 Volker Reichelt 2004-10-06 17:18:42 UTC
The bug can be triggered by "-O -fstrength-reduce".
Comment 7 Volker Reichelt 2004-10-06 17:26:49 UTC
And it disappears with "-O2 -fno-strength-reduce".
Comment 8 Andrew Pinski 2004-10-06 17:37:25 UTC
This is most likely related to PR 16052.
Comment 9 Andrew Pinski 2004-10-06 17:40:55 UTC
But more related to PR 13299.
Comment 10 Paolo Bonzini 2004-10-07 10:05:49 UTC
Discussion and patch

http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00622.html

A transformation check_dbra_loop that is causing the miscompilation because it 
uses a != test; not related to 16052 which is about signedness.

Also not related to loop invariant motion.  The source is a bogus 
NOTE_INSN_LOOP_VTOP note: after CSE and GCSE's constant propagation, the loop 
is not anymore a duplicate of the loop-entry test:

   if (i < 2)
     do
       foo = 0, i++;
     while (i < 0);

is not reducible to a while loop, while loop thinks it is because the VTOP note 
remains.
Comment 11 Richard Biener 2004-10-07 10:18:40 UTC
Subject: Re:  Wrong generated code for loop with
 varying bound

> Also not related to loop invariant motion.  The source is a bogus
> NOTE_INSN_LOOP_VTOP note: after CSE and GCSE's constant propagation, the loop
> is not anymore a duplicate of the loop-entry test:

Yes, 06.cse is the first wrong dump for with -O, 04.jump looks sane.

Comment 12 Andrew Pinski 2004-11-21 01:39:56 UTC
The reason why I say this can never even happen on 4.0 is because the loop notes are not done until 
after the "new" rtl-loop pass is done.
Comment 13 Paolo Bonzini 2005-02-10 12:51:07 UTC
Oh, and VTOP notes were killed on mainline.
Comment 14 Paolo Bonzini 2005-08-09 08:23:05 UTC
Patch committed.
Comment 15 CVS Commits 2005-08-09 08:23:06 UTC
Subject: Bug 17860

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	bonzini@gcc.gnu.org	2005-08-09 08:22:55

Modified files:
	gcc            : ChangeLog loop.c 

Log message:
	2005-08-09  Paolo Bonzini  <bonzini@gnu.org>
	
	PR rtl-optimization/17860
	* loop.c (check_dbra_loop): Do not try to use an end condition
	like "i != 0" in the reversed loop.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.906&r2=2.2326.2.907
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/loop.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.488.2.8&r2=1.488.2.9