https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Eric Botcazou from comment #9) > > Then I don't understand the problem in the BIT_NOT_EXPR case: we have int > > type and [0, 1] range for rhs; if we know that BIT_NOT_EXPR is zero, we can > > deduce that it must be 1 too. > > So the problem is in the non-zero case? Maybe add a test on integer_onep? On the testcase, value is -2 and before your change it would derive correctly that if BIT_NOT_EXPR is -2, then rhs must be ~-2, i.e. 1, but after the patch it says rhs must be 0. Adding integer_onep wouldn't be correct IMHO, if you have some non-boolean non-prec==1 integral type, even if you know rhs has range [0, 1], if BIT_NOT_EXPR should be assumed to have value 0, then rhs needs to be assumed to have value ~0, i.e. -1, rather than 1, and similarly if BIT_NOT_EXPR has value 1, then rhs needs to be assumed to have value ~1, i.e. -2, rather than 0. Due to actual value range that will turn to be something impossible, but what the boolean-ish case does is just not correct for non-boolean.
