https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97721
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu.org
--- Comment #2 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
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.
