17860 – [3.4 only] Wrong generated code for loop with varying bound (original) (raw)

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 Drea Pinski 2004-10-06 12:55:08 UTC

Since this is not a regression closing as fixed for 4.0.0.

Comment 2 Drea 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 Drea 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🔞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 Drea Pinski 2004-10-06 17:37:25 UTC

This is most likely related to PR 16052.

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🔞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 Drea 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.