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