https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97760
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> --- t.c:9:12: note: worklist: examine stmt: i_16 = PHI <i_11(5), 3(2)> t.c:9:12: note: vect_is_simple_use: operand (int) _3, type of def: reduction t.c:9:12: note: reduc-stmt defining reduc-phi in the same nest. t.c:9:12: note: mark relevant 1, live 1: i_11 = (int) _3; so reduc PHI defs are marked live magically - that's obviously wrong here, the live stmt is one in the middle of the reduction path (which _is_ marked live). What happens is that we generate two vectorized epilogues and depending on the order we end up with the wrong result in b. Now, what's _also_ wrong is that we cannot handle this situation since the epilogue of the middle stmt fails to account for the all-but-the-last lane effect of the _not_ live stmt. While the former bug is easy to fix the latter is not. I have a patch.
