https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85598
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amacleod at redhat dot com
--- Comment #20 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #3)
> So, during evrp we have:
> <bb 2> :
> goto <bb 4>; [INV]
>
> <bb 3> :
> __builtin_snprintf (&temp, 4, "%%%02X", x_1);
> # RANGE [1, 256] NONZERO 511
> x_6 = x_1 + 1;
>
> <bb 4> :
> # RANGE [0, 256] NONZERO 511
> # x_1 = PHI <0(2), x_6(3)>
> if (x_1 != 256)
> goto <bb 3>; [INV]
> else
> goto <bb 5>; [INV]
>
> and that is correct and maximum of what we can achieve, x_1 indeed has [0,
> 256] range and only perhaps on-demand vrp analysis improvements can help
> there for the use in bb 3.
Indeed.
FWIW, this is handled correctly in the on-demand ranger branch. There we see
that the x_1 used in BB3 (snprintf) has a range of [0, 255]:
=========== BB 3 ============
x_1 [0, 255] unsigned int
<bb 3> :
snprintf (&temp, 4, "%%%02X", x_1);
x_7 = x_1 + 1;
x_7 : [1, 256] unsigned int
This is because the ranger can see that even though x_1 is known to be [0, 256]
in BB4, on the BB4 -> BB3 edge, it doesn't contain 256:
=========== BB 4 ============
<bb 4> :
# x_1 = PHI <0(2), x_7(3)>
if (x_1 <= 255)
goto <bb 3>; [INV]
else
goto <bb 5>; [INV]
x_1 : [0, 256] unsigned int
4->3 (T) x_1 : [0, 255] unsigned int
4->5 (F) x_1 : [256, 256] unsigned int
But of course, that doesn't help mainline :).
