http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60656
--- Comment #4 from Cong Hou <congh at google dot com> --- Yes, there is a quick fix: we can check if the def with vect_used_by_reduction is immediately used by a reduction stmt. After all, it seems that supportable_widening_operation() is the only place that takes advantage of this "the element order doesn't matter" feature. diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c index 70fb411..7442d0c 100644 --- a/gcc/tree-vect-stmts.c +++ b/gcc/tree-vect-stmts.c @@ -7827,7 +7827,16 @@ supportable_widening_operation (enum tree_code code, gimple stmt, stmt, vectype_out, vectype_in, code1, code2, multi_step_cvt, interm_types)) - return true; + { + tree lhs = gimple_assign_lhs (stmt); + use_operand_p dummy; + gimple use_stmt; + stmt_vec_info use_stmt_info = NULL; + if (single_imm_use (lhs, &dummy, &use_stmt) + && (use_stmt_info = vinfo_for_stmt (use_stmt)) + && STMT_VINFO_DEF_TYPE (use_stmt_info) == vect_reduction_def) + return true; + } c1 = VEC_WIDEN_MULT_LO_EXPR; c2 = VEC_WIDEN_MULT_HI_EXPR; break;