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

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

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

--- Comment #2 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
The point of the builder is that, if you know the pattern,
you don't need to supply every element value to the builder.
(And indeed you can't when the vector is variable length.)

So something might push:

  { a, b, c, ... }

and leave the other elements implicit.  Same when computing
the result of adding two vectors with the same pattern
(new_binary_operation).  It might be that the overflow
happens in elements that are not encoded.  But something
later could still ask for the value of the fourth or fifth
element and get something that overflows, even if the vector
itself is not marked as overflowing.

E.g. to take chars as an example, we could build:

    { 0x3c, 0x3d, …, 0x43 }
  + { 0x3c, 0x3d, …, 0x43 }

by pushing all 8 elements of each vector, and seeing the
overflow for 0x40+0x40.  We'd then set TREE_OVERFLOW on
the VECTOR_CST.  But we could also just push 0x3c, 0x3d, 0x3e,
add those together, and get the same constant without the
TREE_OVERFLOW.

So I'm not sure that TREE_OVERFLOW on a VECTOR_CST is really meaningful.