https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97721
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #2)
> The ranger is analyzing a statement with an integer overflow, and creating a
> non-legacy range that is invalid:
>
> (gdb) p debug(stmt)
> if (_1 != -1(OVF))
>
> (gdb) p debug(op2_range)
> int [-1(OVF), -1(OVF)]
>
> (gdb) p op2_range.legacy_mode_p()
> $8 = false
>
> Legacy ranges allow TREE_OVERFLOW to creep in, as the verifier allows
> symbolics and other end points that are not comparable at compile time (cmp
> == -2 below):
>
> case VR_ANTI_RANGE:
> case VR_RANGE:
> {
> gcc_assert (m_num_ranges == 1);
> int cmp = compare_values (tree_lower_bound (0), tree_upper_bound (0));
> gcc_assert (cmp == 0 || cmp == -1 || cmp == -2);
> return;
> }
>
> However, we're a bit more strict in irange. We don't allow un-comparable
> endpoints and TREE_OVERFLOW integers are such.
>
> I'm not sure where to fix this.
>
> Is the original statement valid gimple? Richard has mentioned that any time
> there's a TREE_OVERFLOW in the IL, it's a sign of a bug. If the IL is
> wrong, we should tackle the source problem.
>
> If the IL is ocrrect, then perhaps we could drop OVF at range creation.
Yes, the IL is "correct", just inefficent and possibly confusing to passes.
The OVF flag on INTEGER_CST have _no_ semantic meaning in the IL so making
them "invalid" in ranger doesn't make sense.
