The following avoids associating a reduction path as that might
get STMT_VINFO_REDUC_IDX out-of-sync with the SLP operand order.
This is a latent issue with SLP reductions but now easily exposed
as we're doing single-lane SLP reductions.
When we achieved SLP only we can move and update this meta-data.
PR tree-optimization/115669
* tree-vect-slp.cc (vect_build_slp_tree_2): Do not reassociate
chains that participate in a reduction.
* gcc.dg/vect/pr115669.c: New testcase.
(cherry picked from commit
7886830bb45c4f5dca0496d4deae9a45204d78f5)
--- /dev/null
+/* { dg-additional-options "-fwrapv" } */
+
+#include "tree-vect.h"
+
+int a = 10;
+unsigned b;
+long long c[100];
+int foo()
+{
+ long long *d = c;
+ for (short e = 0; e < a; e++)
+ b += ~(d ? d[e] : 0);
+ return b;
+}
+
+int main()
+{
+ check_vect ();
+ if (foo () != -10)
+ abort ();
+ return 0;
+}
else if (is_a <loop_vec_info> (vinfo)
/* ??? We don't handle !vect_internal_def defs below. */
&& STMT_VINFO_DEF_TYPE (stmt_info) == vect_internal_def
+ /* ??? Do not associate a reduction, this will wreck REDUC_IDX
+ mapping as long as that exists on the stmt_info level. */
+ && STMT_VINFO_REDUC_IDX (stmt_info) == -1
&& is_gimple_assign (stmt_info->stmt)
&& (associative_tree_code (gimple_assign_rhs_code (stmt_info->stmt))
|| gimple_assign_rhs_code (stmt_info->stmt) == MINUS_EXPR)