https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69586
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |missed-optimization
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
So with -fshort-enums clnt_stat is unsigned QImode and we have before VRP/DOM
<bb 2>:
_9 = do_ypcall_tr ();
result_10 = (clnt_stat) _9;
if (result_10 != 0)
goto <bb 3>;
else
goto <bb 4>;
<bb 3>:
_11 = _9 & 255;
goto <bb 5>;
<bb 4>:
_12 = __builtin_strdup ("foo");
<bb 5>:
# _13 = PHI <_11(3), 0(4)>
# master_19 = PHI <master_20(D)(3), _12(4)>
if (_13 != 0)
where we expect to eventually jump-thread the _13 != 0 test. VRP fails to
add asserts for _9 here because of another INTEGER_TYPE check. Unfortunately
fixing that doesn't make us jump-thread this as we get
Visiting statement:
_21 = ASSERT_EXPR <_9, (unsigned int) _9 + 4294967295 <= 4294967294>;
Intersecting
~[0, 0] EQUIVALENCES: { _9 } (1 elements)
and
VARYING
to
~[0, 0] EQUIVALENCES: { _9 } (1 elements)
Found new range for _21: ~[0, 0]
interesting_ssa_edges: adding SSA use in _11 = _21 & 255;
marking stmt to be not simulated again
Visiting statement:
_11 = _21 & 255;
Meeting
[0, 255]
and
[0, 255]
to
[0, 255]
Intersecting
[0, 255]
and
[-INF, +INF]
to
[0, 255]
Found new range for _11: [0, 255]
this is because BIT_AND_EXPR handling doesn't handle this case very well.
integer
~[0, 0] & 255
is done via [-INT_MIN, -1] & 255 ^ [1, INT_MAX] & 255
and [1, INT_MAX] & 255 results in [0, 255] instead of in [1, INT_MAX].
It may make sense to special-case that & 255 (zero-extend from smaller
precision). Or BIT_AND with anti-ranges in general.
