https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123002
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
Last reconfirmed| |2025-12-04
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
CC| |rguenth at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed. I'm not sure we have a bug for this but I have a patch in my tree
in this area but did not have a testcase for the wrong-code issue (thanks for
providing it!).
My patch notes the issue (but does not fix it):
@@ -5215,10 +5216,32 @@ vectorizable_conversion (vec_info *vinfo,
gcc_assert (!(multi_step_cvt && op_type == binary_op));
break;
}
- if (supportable_widening_operation (vinfo, code, stmt_info,
- vectype_out, vectype_in, &code1,
- &code2, &multi_step_cvt,
- &interm_types))
+ /* Elements in a vector with vect_used_by_reduction property cannot
+ be reordered if the use chain with this property does not have the
+ same operation. One such an example is s += a * b, where elements
+ in a and b cannot be reordered. Here we check if the vector defined
+ by STMT is only directly used in the reduction statement. */
+ if (loop_vinfo
+ && !nested_in_vect_loop_p (LOOP_VINFO_LOOP (loop_vinfo), stmt_info))
+ {
+ tree lhs = gimple_get_lhs (vect_orig_stmt (stmt_info)->stmt);
+ stmt_vec_info use_stmt_info
+ = lhs ? loop_vinfo->lookup_single_use (lhs) : NULL;
+ /* ??? This isn't a sufficient check - the reduction path
+ could have more than a single operation. Also for a SLP
+ reduction we cannot swizzle lanes, only for a reduction
+ chain or a reduction group of size one. We cannot rely
+ on the reduction being analyzed yet, so there is no good
+ way to check whether this is safe, apart from a very
+ conservative SLP_TREE_LANES == 1. This should have been
+ detected as WIDEN_MULT_PLUS_EXPR reduction instead. */
+ if (use_stmt_info && STMT_VINFO_REDUC_DEF (use_stmt_info))
+ evenodd_ok = true;
+ }
+ if (supportable_widening_operation (code, vectype_out, vectype_in,
+ evenodd_ok, &code1,
+ &code2, &multi_step_cvt,
+ &interm_types))
{
