https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123319
Andrew Macleod <amacleod at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |amacleod at redhat dot
com
--- Comment #4 from Andrew Macleod <amacleod at redhat dot com> ---
Created attachment 63222
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=63222&action=edit
proposed fix
Its an issue with intersect and a missed case of range snapping.
The issue is
[irange] int64_t [-INF, -65536][65536, 9223372036854710272] MASK
0xffffffffffff0000
intersect
[irange] int64_t [-1736223011, -1736223011][1, 1]
The intersect operation finds that the first range pair [-1736223011,
-1736223011] is contained, but the second one isn't. It builds a range with
the SAME bitmask, and the bug is that we do not snap the range to valid values
before we perform the bitm asmk intersection.
If we had, we would have recognized that -1736223011 is NOT valid with the
bitmask, and the intersection should return UNDEFINED.
Instead, it creates the range
[irange] int64_t [-1736223011, -1736223011] MASK 0xffffffffffff0000 VALUE 0x0
With the same bitmask, and then expects bitmask intersect to fix it.
Unfortunately, bitmask intersect has a shortcut that if the masks are the same,
it doesnt need to do anything, expecting that the bounds snapping has already
happened, and saving a lot of unnecessary cycles.
Instead, once intersect builds the new set of subranges, it should immediately
snap the bounds for the current bitmask before invoking bitmask intersect,
which will only deal with snapping that is required if there is an actual
bitmask intersection
