On Thu, May 15, 2025 at 7:02 PM Andrew MacLeod <amacl...@redhat.com> wrote: > > Recent changes to get_range_from_bitmask can sometimes turn a small > range into an undefined one if the bitmask indicates the bits make all > values impossible. > > range_cast () was not expecting this and checks for UNDEFINED before > peforming the cast. It also needs to check for it after the cast now. > > in this testcase, the pattern is > > y = x * 4 <- we know y will have the bottom 2 bits cleared > z = Y + 7 <- we know z will have the bottom 2 bit set. > > then a switch checks for z == 128 | z== 129 and performs a store into > *(int *)y > eventually the store is eliminated as unreachable, but range analysis > recognizes that the value is UNDEFINED when [121, 122] with the last 2 > bits having to be 11 is calculated :-P > > Do the default for casts, and if the result is UNDEFINED, turn it into > VARYING. > > Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
For unreachable code it probably does not matter much. but IMO dropping from UNDEFINED to VARYING within the core ranger is pessimizing and could end up papering over issues that would otherwise show up. IMO such UNDEFINED -> VARYING should happen at the consumer side or alternatively a uppermost API layer that's not used from within ranger itself. Richard. > > Andrew
