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;