https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Eric Botcazou from comment #12) > > 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. > > With this line of reasoning, how can the BIT_AND_EXPR case be correct? So, for BIT_AND_EXPR we only handle the case where the result of BIT_AND_EXPR is known to be non-zero. That means both operands have to be non-zero (and have at least one common bit). Now, if say the operation is done on int and we know that rhs1 (or rhs2 or both) have [0, 1] range, that means we can safely assume that BIT_AND_EXPR is non-zero implies that rhs1 (or rhs2 or both) are 1.
