https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94021
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I don't understand why EVRP would be relevant, strlen pass runs after VRP1.
Anyway, I see two issues. One general problem with SSA_NAME_RANGE_INFO
applying to SSA_NAME and thus it needs to cover ranges in all possible spots
the SSA_NAME is set or used, where during VRP where we have ASSERT_EXPRs we
find the right range but as it is just used in the bb guarded by the
conditional, there is nothing to stick it on (as compared to e.g. if the
sprintf was using h + 1 instead of h, where on the SSA_NAME holding h + 1 we
could add SSA_NAME_RANGE_INFO). For this consider e.g.
char a[8];
void format_utc_offset (int x, int h)
{
if (x < 0)
x = -x;
int m = (x % 3600) / 60;
if (h < 0 || h >= 24 || m < 0 || m >= 60)
__builtin_puts ("");
if (0 <= m && m <= 60 && 0 <= h && h <= 24)
__builtin_snprintf (a, sizeof a, "%s%02i%02i", "+", h, m);
}
where it warns too. This is something that the value ranger work by
Andrew/Aldy could help with.
The other, on the #c4 case, is that match.pd seems to optimize e.g. the h <= 24
into x <= 24 * 3600 + 3599. And that is really weird, because:
/* X / C1 op C2 into a simple range test. */
(for cmp (simple_comparison)
(simplify
(cmp (trunc_div:s @0 INTEGER_CST@1) INTEGER_CST@2)
as it uses :s and so in my understanding shouldn't match because the h SSA_NAME
has multiple uses (e.g. is also used in the snprintf call).
And I bet this problem is what would prevent even the ranger for determining
something useful in this case.
