make it build with llvm 22

[el-ev]

No description provided.

[el-ev]

Is that a false alarm? for unsigned char, 4294967046 % 256 == 6.

[vtjnash]

yeah, claude figured out thats a separate bug in the test:

That's test_char_sized_ptr_math_decr — the file you were asking about. And it is not caused by PR 240; it's a latent flake in the test itself.

At -O1/-O2 LLVM folds the whole thing to arithmetic on &a, with zext(trunc i8) narrowed to and 252 (low 2 bits known zero from alignment):

return ((llvm_sub_u32((((uint32_t)(uintptr_t)(&a)) & 252),
(((uint32_t)(uintptr_t)((uint8_t*)(&a) - 4)) & 252))) | 2);

The result depends on the low byte of the stack address of a. Since a is 4-byte aligned, &a & 255 ∈ {0, 4, …, 252}, and the byte-truncated subtraction wraps for exactly one of those 64 values:

addr low byte 0x00 -> 4294967046 <-- the CI failure, 2^32-250
addr low byte 0x40 -> 6
addr low byte 0x04 -> 6

(That's the CBE -O1 body run against forced addresses; 400 consecutive runs of the real binary on Linux gave 6 every time.) So it's a ~1-in-64 stack-address lottery, and the Windows runner drew the losing ticket — the
reference MSVC binary got a non-zero low byte and returned 6, the CBE binary got 0x00. Master's Windows job passed on the run one day earlier with no code difference in this path.

Worth noting the C source has the same address dependence — unsigned char inc0/inc1 with inc0 - inc1 in int arithmetic underflows identically. So the test is testing something genuinely unspecified-ish, not a CBE bug.
The fix belongs in the test (e.g. mask the difference, or compare (unsigned char)(inc0 - inc1)), not in PR 240 — and it's an argument for re-running the Windows job rather than blocking the PR on it.