Bug 23115

Summary: [4.1 Regression] -ftree-vectorize generates wrong code
Product: gcc Reporter: p.van-hoof
Component: tree-optimizationAssignee: Devang Patel <dpatel>
Status: RESOLVED FIXED    
Severity: critical CC: dnovillo, dpatel, gcc-bugs, sje
Priority: P2 Keywords: wrong-code
Version: 4.1.0   
Target Milestone: 4.1.0   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed: 2005-09-25 23:41:31
Bug Depends on:    
Bug Blocks: 31966    
Attachments: code that triggers the bug

Description p.van-hoof 2005-07-28 18:39:54 UTC 
The vectorizer generates wrong code for the attached example

dogbert> gcc o.c
dogbert> a.out
 this is where I should be (R = 1.0e+00)...
dogbert> gcc -O1 -ftree-vectorize o.c
dogbert> a.out
 I should not be here (R = -1.0e+300)...
dogbert> gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/gcc410
--enable-languages=c,c++,f95
Thread model: posix
gcc version 4.1.0 20050725 (experimental)

This behavior shows up on the mainline, but not the 4.0 branch. I could
reproduce the problem on i686-pc-linux-gnu, x86_64-unknown-linux-gnu, and
sparc-sun-solaris2.9, so doesn't seem to be target specific.
Comment 1 p.van-hoof 2005-07-28 18:40:54 UTC 
Created attachment 9380 [details]
code that triggers the bug
Comment 2 Andrew Pinski 2005-07-28 18:51:44 UTC 
This is caused by tree if conversion.
Comment 3 Andrew Pinski 2005-09-08 20:03:34 UTC 
Before:
  if (x_16 < x_26) goto <L3>; else goto <L14>;

<L14>:;

  # x_4 = PHI <x_26(1), x_16(2)>;
<L3>:;
  if (x_16 > n_17) goto <L6>; else goto <L15>;

<L15>:;

  # n_5 = PHI <n_17(3), x_16(4)>;
<L6>:;

After:
  x_4 = x_16 < x_26 ? x_26 : x_16;
  n_5 = 1 ? n_17 : x_16;

That 1 is just wrong.
Comment 4 Janis Johnson 2005-09-09 22:18:32 UTC 
A regression hunt of mainline on powerpc-linux shows that the test starts
failing with a merge from tree-cleanup-branch on 20050409.  The test passes,
however, with a compiler built after the final patch was added to that branch
on 20050401; looks like it could be a merge problem.
Comment 5 Devang Patel 2005-09-30 23:52:00 UTC 
Assign this bug to me. Thanks.
Comment 6 Andrew Pinski 2005-09-30 23:54:21 UTC 
(In reply to comment #5)
> Assign this bug to me. Thanks.
Done, you also now have the premissions to do that yourself.
Comment 7 Mark Mitchell 2005-10-31 04:23:29 UTC 
I'm on the fence as to whether to call this P1 or P2.  People have really started to use -ftree-vectorize and it's a major advantage of the more recent compilers over 3.4.x, so I'd really like to see this fixed.  On the other hand, I'm not quite willing to call this a showstopper, so ... P2.
Comment 8 Devang Patel 2005-11-08 02:22:59 UTC 
tree if-conversion  was expecting perfect dimond, but it is not always true after tree-cleanup-branch work. I've started overnight patch test run. Hopefully, I'll send patch tomorrow for review.
Comment 9 Devang Patel 2005-11-08 20:21:21 UTC 
Subject: Bug 23115

Author: dpatel
Date: Tue Nov  8 20:21:15 2005
New Revision: 106653

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106653
Log:
       PR tree-optimization/23115
       * tree-if-conv.c (find_phi_replacement_condition): Check domninated_by
       relation.

       * gcc.dg/tree-ssa/pr23115.c: New.


Added:
    trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23115.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-if-conv.c
Comment 10 Andrew Pinski 2005-11-08 22:13:26 UTC 
Fixed.
Comment 11 Uroš Bizjak 2007-07-01 13:40:35 UTC 
(In reply to comment #9)

>        PR tree-optimization/23115
>        * tree-if-conv.c (find_phi_replacement_condition): Check domninated_by
>        relation.

This fix is not enough to solve problems described in Comment #8. Actually, the condition, introduced by attached patch:

+      || dominated_by_p (CDI_DOMINATORS, second_bb, first_bb))

doesn't even trigger anymore for the testcase in this PR, and at least gcc 4.3.0 passes mentioned testcase _only_ due to slightly different CFG. However, the same problem (wrong handling of non perfect diamond) is the root cause of PR 31966.

It is up to bugmaster to reopen this PR, as the fix is not effective.
Comment 12 Uroš Bizjak 2007-07-04 05:53:19 UTC 
(In reply to comment #11)

> It is up to bugmaster to reopen this PR, as the fix is not effective.

This is OK to leave as fixed.