[Bug middle-end/110495] fre introduces signed wrap for vector

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110495

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org,
                   |                            |rsandifo at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |wrong-code
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-06-30
          Component|tree-optimization           |middle-end

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Applying pattern match.pd:3029, gimple-match-2.cc:1090
Applying pattern match.pd:3029, gimple-match-2.cc:1090

but that specifically checks for

         (if (cst && !TREE_OVERFLOW (cst))
          (inner_op @0 { cst; } )

ah, but we are dealing with vectors here and the VECTOR_CST doesn't
inherit TREE_OVERFLOW here.  I don't think we ever actually set
TREE_OVERFLOW on VECTOR_CSTs even though that's documented to be a thing.

We are relying on TREE_OVERFLOW in some more patterns that are also
applying to VECTOR_CST.  _Complex int is probably similarly affected.

diff --git a/gcc/tree-vector-builder.cc b/gcc/tree-vector-builder.cc
index 0e51bcefa4f..78688ef4331 100644
--- a/gcc/tree-vector-builder.cc
+++ b/gcc/tree-vector-builder.cc
@@ -43,6 +43,12 @@ tree_vector_builder::build ()
   gcc_assert (pow2p_hwi (npatterns ()));
   tree v = make_vector (exact_log2 (npatterns ()), nelts_per_pattern ());
   TREE_TYPE (v) = m_type;
+  bool ovf = false;
+  for (tree elt : *this)
+    if (TREE_OVERFLOW (elt))
+      ovf = true;
+  if (ovf)
+    TREE_OVERFLOW (v) = true;
   memcpy (VECTOR_CST_ENCODED_ELTS (v), address (),
          encoded_nelts () * sizeof (tree));
   return v;

fixes this and results in

  <bb 2> :
  _1 = *x_6(D);
  _2 = _1 + { 2147483647, 2147483647, 2147483647, 2147483647, 2147483647,
2147483647, 2147483647, 2147483647, 2147483647, 2147483647, 2147483647,
2147483647, 2147483647, 2147483647, 2147483647, 2147483647 };
  *x_6(D) = _2;
  _9 = VIEW_CONVERT_EXPR<vector(16) unsigned int>(_1);
  _10 = _9 + { 4294967294, 4294967294, 4294967294, 4294967294, 4294967294,
4294967294, 4294967294, 4294967294, 4294967294, 4294967294, 4294967294,
4294967294, 4294967294, 4294967294, 4294967294, 4294967294 };
  _4 = VIEW_CONVERT_EXPR<vector(16) int>(_10);
  *x_6(D) = _4;
  return;

there are some more VECTOR_CST builders that would need adjustment for
consistency.  Maybe not relying on TREE_OVERFLOW would be a better idea
here, but while for plain integers we have wide_int for vectors or
complex there's no such thing ...