https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103079
--- Comment #9 from Andrew Macleod <amacleod at redhat dot com> --- Created attachment 51735 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51735&action=edit patch for the undefined bit (In reply to Richard Biener from comment #7) > =========== BB 2 ============ > Imports: b.0_1 t_4(D) > Exports: b.0_1 t_4(D) _6 > _6 : b.0_1(I) t_4(D)(I) > t_4(D) UNDEFINED > <bb 2> [local count: 176285970]: > b.0_1 = b; > _6 = b.0_1 | t_4(D); > if (_6 != 0) > goto <bb 3>; [34.00%] > else > goto <bb 7>; [66.00%] > > 2->3 (T) b.0_1 : UNDEFINED > 2->3 (T) t_4(D) : UNDEFINED > 2->3 (T) _6 : int [-INF, -1][1, +INF] > > I think 2->3 (T) b.0_1 : UNDEFINED is wrong. if b.0_1 is 1 then 1 | UNDEF > is still 1 and there's nothing "undefined" in evaluating if (1 | UNDEF !+ 0). yeah looks like gori calculations just assumes an undefined argument makes everything undefined.. we should probably just left the op1/op2_range routines handle it. We can't actually know b.0_1 if the branch is taken because of the undefined, so it'll get calculated as varying. With the untested patch, we now get 2->3 (T) t_4(D) : UNDEFINED 2->3 (T) _6 : int [-INF, -1][1, +INF] 2->7 (F) b.0_1 : int [0, 0] 2->7 (F) t_4(D) : UNDEFINED 2->7 (F) _6 : int [0, 0] we do know that b.0_1 is 0 on the false side...
