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.
Created attachment 9380 [details] code that triggers the bug
This is caused by tree if conversion.
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.
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 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
Fixed.
(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.
(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.