https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77898
--- Comment #3 from Marc Glisse <glisse at gcc dot gnu.org> --- (In reply to Martin Sebor from comment #2) > I may also be confused about other things but below is what I see in GDB > when I call get_range_info() from plus_stmt_object_size() on the offset in > POINTER_PLUS_EXPR (get_offset_range is a function I've added in my patch for > bug 77608). As best I can tell the anti-range doesn't correspond to the > range of the variable i which is [0, 1]. You seem to be assuming that EVRP is clever enough to find out that the range of i_4 is [0, 1], as VRP1 does. However, EVRP is a limited version, which doesn't manage it in this case. All it knows is that _2 is an unsigned long obtained by casting from some arbitrary int, so its range is the union of [0, INT_MAX] (if the int is non-negative) and [ULONG_MAX+INT_MIN+1,ULONG_MAX] (if the int is negative), which is represented as an anti-range. This conservative (anti-)range is valid, since it contains [0,1]. Now maybe evrp could be enhanced to find a tighter range without making it too costly, I don't know.
