On Wed, Jan 7, 2026 at 5:08 AM Richard Biener <[email protected]> wrote: > > 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.
Note the testcase does not work on anything non-x86. I have placed a new reduced testcase in the bug report which does not use vectors nor x86 specific functions/headers. Does it make sense to replace the broken non working testcase with that one? Or keep the old one and mark it as being compiled only for x86 and then add the new one? Thanks, Andrew > > Richard. > > > > > Andrew
