On Mon, May 5, 2025 at 9:55 PM Andrew MacLeod <amacl...@redhat.com> wrote: > > > On 5/3/25 07:41, Richard Biener wrote: > > 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. > > This is the patch applied to GCC 15. > > Bootstraps on x86_64-pc-linux-gnu with no regressions. OK for the GCC > 15 release branch?
OK. > > Andrew
