In g:76c3041b856cb0 I'd removed a "C ? optab_vector : optab_mixed_sign"
argument from a call to directly_supported_p, thinking that the argument
only existed because of the condition (which I was removing).  But the
difference between the scalar and vector forms matters for shifts,
so we do still need the argument.

Tested on aarch64-linux-gnu and pushed as obvious.

Richard


gcc/
        PR tree-optimization/106250
        * tree-vect-loop.cc (vectorizable_reduction): Reinstate final
        argument to directly_supported_p.
---
 gcc/testsuite/gcc.dg/vect/pr106250.c | 17 +++++++++++++++++
 gcc/tree-vect-loop.cc                |  2 +-
 2 files changed, 18 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/vect/pr106250.c

diff --git a/gcc/testsuite/gcc.dg/vect/pr106250.c 
b/gcc/testsuite/gcc.dg/vect/pr106250.c
new file mode 100644
index 00000000000..7f25f551869
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr106250.c
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+
+int
+foo (unsigned long int x, int y, int z)
+{
+  int ret = 0;
+
+  while (y < 1)
+    {
+      x *= 2;
+      ret = x == z;
+      z = y;
+      ++y;
+    }
+
+  return ret;
+}
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 3a70c15b593..2257b29a652 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -7369,7 +7369,7 @@ vectorizable_reduction (loop_vec_info loop_vinfo,
         dot-products.  */
       machine_mode vec_mode = TYPE_MODE (vectype_in);
       if (!lane_reduc_code_p
-         && !directly_supported_p (op.code, vectype_in))
+         && !directly_supported_p (op.code, vectype_in, optab_vector))
         {
           if (dump_enabled_p ())
             dump_printf (MSG_NOTE, "op not supported by target.\n");
-- 
2.25.1

Reply via email to