https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106884
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> --- To clarify for the original testcase, ifcombine combines the two bit tests (x & (1<<a)) && (x & (1<<b)) to x & ((1<<a) | (1<<b)) == ((1<<a) | (1<<b)). We can rely on 1<<a being non-zero, otherwise the testcase invoked undefined behavior. That means whatever value 1<<b produced in the case it was unspecified we still get false when bit 1<<a was not set and a defined value when the value of 1<<b was well-defined. But yes, since we now unconditionally compute 1<<b after the transform GCC could assume b is in range. We are lacking a way to compute 1<<b optimally without that undefined behavior.
