On Thu, Oct 23, 2025 at 8:49 PM Andrew MacLeod <[email protected]> wrote: > > The attached patch fixes PR 118254. > > It does 2 things: > > 1) when performing a cast, we cast sub pairs and union the results. > When this gets to VARYING we immediately short circuit and return. > THe error was if there was a bitmask, it was nebver attached and > applied. This patch correct that such that the bitmask is now applied > to a VARYING result, which may result in something that is not VARYING > any more. > > 2) Operator_cast::op1_range makes no attempt to set a bitmask for > truncating casts... The observation is that given: > > x_2 = (char) b_4 > > if x_2 is known to have a range of unsigned char [0, 7] MASK 0x7 VALUE > 0x0 , then we can also determine that b_4's lower 8 bits must also have > the same mask... > > > This bootstraps fine, but causes a single regression. It appears to > make the bug in PR 111003 no longer latent ( > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111003 ). > > For the testcase in that PR, we are presented with : > > <bb 2> [local count: 1073741824]: > c.0_1 = c; > _2 = (unsigned char) c.0_1; > goto <bb 4>; [100.00%] > > < - snip- > > > <bb 7> [local count: 70290166531]: > if (_2 != 0) > goto <bb 8>; [50.00%] > else > goto <bb 12>; [50.00%] > > The edge from 7->12 knows that _2 == [0,0] and for c.0_1, ranger use to > generate the range [-INF, -256][0, 0][256, +INF]. > > WIth this patch, the appropriate bitmask is added in > operator_cast::op1_range() , and now c.0_1 == [-INF, -256][0, 0][256, > 2147483392] MASK 0xffffff00 VALUE 0x0 > > Note this allows us to carry the knowledge that the lower 8 bits are > zero. THis then feeds into > > <bb 12> [local count: 58340838140]: > _4 = c.0_1 & 255; > _12 = (unsigned int) _4; > if (_4 > 6) > goto <bb 13>; [50.00%] > else > goto <bb 14>; [50.00%] > > Where previously, _4 was calculated as [-INF, -256][0, 0][256, > +INF] & 255 , which comes out VARYING. > > With this patch, we produce [-INF, -256][0, 0][256, 2147483392] MASK > 0xffffff00 VALUE 0x0 & 255, and come up with _4 == 0. > > That then causing that IF statement to never be true on this path, and > the threader makes a different set of decisions on this new information > in threadfull2. > > That in turns seems to reactivate the bug in PR 111003. I've looked at > it a bit, but its not in my wheelhouse so I havent made much progress > > The attached patch fixes 118254, but causes 111003 to regress. Should I > commit it, close 118254, and reopen 111003? Or should I hold off on > this patch?
I'd say commit it and re-open the bug - it has not been "fixed", but it was made latent anyway. Richard. > > Thanks > > Andrew >
