https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121519
--- Comment #8 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Jakub Jelinek from comment #7) > It doesn't reproduce since r16-4253-g13f5a627dcab882fdf9183f96a8270c7f5229f95 Ah, that makes sense. That patch forced all range bounds to match the bitmask. In the testcase, a range was presented which had a few subranges, none of which were consistent with the bitmask. So it was really an UNDEFINED range when the bitmask is applied... It didnt turn into an actual UNDEFINED until part way through the calculations that were being done in lshift::op1_range... so it looked like a range that when we cast it to the unsigned variant of type, and performed a shift by one suddenly went to UNDEFINED. In theory, that shouldn't happen any more :-P I think we can just say that patch also fixed this PR.
