[Bug tree-optimization/112807] ICE: SIGSEGV in contains_struct_check (tree.h:3747) with _BitInt() at -O1 and above

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

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ah, the problem is that lower_addsub_overflow was written for lowering of
large/huge _BitInt operations, so for .{ADD,SUB}_OVERFLOW where one of the 2
operands is in the x86_64 case at least 129 bit or the result is a complex type
with 129+ bit element type.
That is the case here, because the first operand is _BitInt(256), but as result
is just 32-bit and VRP tells us the first argument is in [0, 0xffffffff] range
which needs 32-bits unsigned and the second argument is in [-2, 1] range, we
don't actually cast the second argument to a large/huge _BitInt type and so it
fails miserably.
Now, we could fix that either by tweaking the
  tree type0 = TREE_TYPE (arg0);
  tree type1 = TREE_TYPE (arg1);
  if (TYPE_PRECISION (type0) < prec3)
    {
      type0 = build_bitint_type (prec3, TYPE_UNSIGNED (type0));
      if (TREE_CODE (arg0) == INTEGER_CST)
        arg0 = fold_convert (type0, arg0);
    }
  if (TYPE_PRECISION (type1) < prec3)
    {              
      type1 = build_bitint_type (prec3, TYPE_UNSIGNED (type1));
      if (TREE_CODE (arg1) == INTEGER_CST)
        arg1 = fold_convert (type1, arg1);
    }
such that if bitint_precision_kind (prec3) < bitint_prec_large we actually use
smallest possible bitint_prec_large, or during the preparation phase check if
.{ADD,SUB}_OVERFLOW with small/medium return and both operands with
range_for_prec absolute values also small/medium we actually turn it into a
small/medium .{ADD,SUB}_OVERFLOW and expand just the casts.