The vectorizer generates wrong code for the attached example
dogbert> gcc o.c
this is where I should be (R = 1.0e+00)...
dogbert> gcc -O1 -ftree-vectorize o.c
I should not be here (R = -1.0e+300)...
dogbert> gcc -v
Using built-in specs.
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.
Created attachment 9380 [details]
code that triggers the bug
This is caused by tree if conversion.
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.
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.
Assign this bug to me. Thanks.
(In reply to comment #5)
> Assign this bug to me. Thanks.
Done, you also now have the premissions to do that yourself.
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.
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.
Subject: Bug 23115
Date: Tue Nov 8 20:21:15 2005
New Revision: 106653
* tree-if-conv.c (find_phi_replacement_condition): Check domninated_by
* gcc.dg/tree-ssa/pr23115.c: New.
(In reply to comment #9)
> PR tree-optimization/23115
> * tree-if-conv.c (find_phi_replacement_condition): Check domninated_by
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.
(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.