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