[Bug tree-optimization/97721] [11 Regression] ICE in verify_range, at value-range.cc:361

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #8)
> (In reply to Jakub Jelinek from comment #7)
> > But TREE_OVERFLOW is meaningful during evaluation, e.g. inside of VRP or
> > when folding some expression.  It just doesn't belong into the GIMPLE IL.
> > So I'd say it would be better for ranger when it sees TREE_OVERFLOW constant
> > somewhere in the IL not to set the range to that constant, but to
> > drop_tree_overflow of it.
> 
> That's certainly the easiest path for us.  We could drop_overflow in
> get_tree_range while creating said ranges, and then no other changes to the
> ranger are needed.
> 
> However, I wonder if compare_values_warnv is being unnecessarily
> restrictive.  For example, here, we bail on overflow, even though
> tree_int_cst_compare, through its use of wi::cmps, is perfectly capable of
> comparing these integers:
> 
>   if (!POINTER_TYPE_P (TREE_TYPE (val1)))
>     {
>       /* We cannot compare overflowed values.  */
>       if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
> 	return -2;
> 
>       if (TREE_CODE (val1) == INTEGER_CST
> 	  && TREE_CODE (val2) == INTEGER_CST)
> 	return tree_int_cst_compare (val1, val2);
> 
> as well as here:
> 
>      if (TREE_CODE (val1) == INTEGER_CST && TREE_CODE (val2) == INTEGER_CST)
> 	{
> 	  /* We cannot compare overflowed values.  */
> 	  if (TREE_OVERFLOW (val1) || TREE_OVERFLOW (val2))
> 	    return -2;
> 
> 	  return tree_int_cst_compare (val1, val2);
> 	}

VRP uses (used to use) fold_* routines and _specifically_ relies (relied)
on some TREE_OVERFLOW bits therein.  This might be all long history
but the above is probably because of that.

Btw, IIRC I've made sure to drop TREE_OVERFLOW from constants picked out
of the IL for VRP purposes (as said, some passes are "confused" about
existing TREE_OVERFLOW if they rely on TREE_OVERFLOW for their own
internal processing - which, nowadays should use wide_int).