We were using the wrong loop to figure the latch arg of a double-reduction PHI. Which isn't a problem in case ->dest_idx match up with the outer loop edges - but that's of course not guaranteed.
Bootstrap & regtest pending on x86_64-unknown-linux-gnu. 2020-10-20 Richard Biener <rguent...@suse.de> * tree-vect-loop.c (vectorizable_reduction): Use the correct loops latch edge for the PHI arg lookup. --- gcc/tree-vect-loop.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c index dceb65c934a..c8747595a63 100644 --- a/gcc/tree-vect-loop.c +++ b/gcc/tree-vect-loop.c @@ -6359,8 +6359,10 @@ vectorizable_reduction (loop_vec_info loop_vinfo, /* Verify following REDUC_IDX from the latch def leads us back to the PHI and compute the reduction chain length. Discover the real reduction operation stmt on the way (stmt_info and slp_for_stmt_info). */ - tree reduc_def = PHI_ARG_DEF_FROM_EDGE (reduc_def_phi, - loop_latch_edge (loop)); + tree reduc_def + = PHI_ARG_DEF_FROM_EDGE (reduc_def_phi, + loop_latch_edge + (gimple_bb (reduc_def_phi)->loop_father)); unsigned reduc_chain_length = 0; bool only_slp_reduc_chain = true; stmt_info = NULL; -- 2.26.2