On Sat, May 3, 2025 at 12:39 AM Andrew MacLeod <amacl...@redhat.com> wrote: > > On trunk I'll eventually do something different.. but it will be more > invasive than I think is reasonable for a backport. > > The problem in the PR is that there is a variable with a range and has a > bitmask attached to it. We often defer bitmask processing, the the > change which triggers this problem "improves" the range by applying the > bitmask when we call update_bitmask. (PR 119712) > > The case in point is a range of 0, combined with a bitmask that says the > '1' bit must be on. This results in an UNDEFINED range since its > impossible. this is rarely a problem but this particular snippet of > code in IPA is tripping over it because it has checked for undefined, > and then created a new range by combining the [0, 0] and the bitmask, > which we turn into an UNDEFINED.. which it isn't expected. and then > it asks for the type of the range. > > As Jakub points out in the PR, this is effectively unreachable code that > is being propagated. A harmless fix would be to check if the result of > applying the bitmask results in an UNDEFINED value and to simply > replace it with a VARYING value. > > WE still reduce the testcase to "return 0" and no more failure. > > bootstraps on -x86_64-pc-linux-gnu with no regressions. > > If this is acceptable, I will push it to trunk, then also test/verify > for the GCC15 and 14(?) branches and check it in there.
LGTM. IPA CP might want to either avoid looking at the type for UNDEFINED or track it separate from the value-range, not sure where it looks at the type of a range. Richard. > Andrew > >
