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 ...
