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.
It appears they don't track undefined at al? l... but thats just a
cursory glance.
On trunk. I think I'll adjust it next week and put the type into the
UNDEFINED range.. I have a functioning patch now. I think its too
pervasive and not really enough of an issue to do that on the release
branches
It'll solve a few of these kinds of things when they pop up, and allow
us to properly do an invert () operation on VARYING and UNDEFINED,
which we have discussed before.
Andrew
