https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, in the debugger the difference is in the range_operator::wi_fold_in_parts
function (with:
enum class A { A0, A1, A2, A3 };
int x;
void baz ();
struct B {
unsigned b : 2;
A
foo () const
{
return static_cast<A> (b);
}
void bar ();
};
void
B::bar ()
{
if (foo () == A::A2 || foo () == A::A3)
baz ();
}
the first one).
type is unsigned:2, lh_lb 0, lh_ub -1 (aka 3), rh_lb and rh_ub -2 (aka 2).
lh_range is -1 (aka 3), rh_range is 0, ov_{l,r}h is OVF_NONE.
In the non-LTO case, we do wi_fold on line 176
171 // Otherise check for 2, 3, or 4 values in the LH range and split
them up.
172 // The RH side has been checked, so no recursion needed.
173 else if (wi::gt_p (lh_range, 0, sign) && wi::lt_p (lh_range, 4, sign)
174 && ov_lh == wi::OVF_NONE)
175 {
176 wi_fold (r, type, lh_lb, lh_lb, rh_lb, rh_ub);
while in the LTO case on line 192.
The wi::lt_p (rh_range, 4, sign) and wi::lt_p (lh_range, 4, sign) calls
look highly suspicious, 4 is not representable in unsigned:2.
