On Tue, Jan 6, 2026 at 6:36 PM Andrew MacLeod <[email protected]> wrote: > > There was a tiny bug in intersection. > > [irange] int64_t [-INF, -65536][65536, 9223372036854710272] MASK > 0xffffffffffff0000 > intersect > [irange] int64_t [-1736223011, -1736223011][1, 1] > > the first range does not contain the second range, but the first > subrange is a component. The resulting range is simply > > [-1736223011, -1736223011] > > But as it is being constructed into the same range and the second range > has no bitmask, the bitnmask remains the same. > > > IN this particular case, bitmask_intersect takes a shortcut and since > the bitmask doesnt change, it doesn't snap the bounds to the the new > bitmask. > > The new range SHOULD be UNDEFINED since this bitmask cannot contain > -1736223011. The intersection routine SHOULD always snap the bounds if > it changed and of the bounds in the new range. > > This was showing up in IPA as we were getting an invalid range to union > with: > > [irange] int64_t [-1736223011, -1736223011] MASK 0xffffffffffff0000 > VALUE 0x0 > > because it had the effect of an UNDFINED during union processing as the > mask was applied, but it was tricking union into thinking it has changes > the range, even though it had not. This sort of choas happens when > the range should be undefined but isn't :-P > > Bootstraps on x86_64-pc-linux-gnu with no regressions, and very minor > performance impact. OK?
OK. Richard. > > Andrew
