Bug 23115 - [4.1 Regression] -ftree-vectorize generates wrong code
Summary: [4.1 Regression] -ftree-vectorize generates wrong code
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.1.0
: P2 critical
Target Milestone: 4.1.0
Assignee: Devang Patel
Keywords: wrong-code
Depends on:
Blocks: 31966
  Show dependency treegraph
Reported: 2005-07-28 18:39 UTC by p.van-hoof
Modified: 2007-07-04 05:53 UTC (History)
4 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2005-09-25 23:41:31

code that triggers the bug (297 bytes, text/plain)
2005-07-28 18:40 UTC, p.van-hoof

Note You need to log in before you can comment on or make changes to this 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
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
  if (x_16 < x_26) goto <L3>; else goto <L14>;


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


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

  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
       PR tree-optimization/23115
       * tree-if-conv.c (find_phi_replacement_condition): Check domninated_by

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


Comment 10 Andrew Pinski 2005-11-08 22:13:26 UTC
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.