[Bug tree-optimization/89536] [8/9 Regression] wrong code at -Os and above on x86_64-linux-gnu

ebotcazou at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Thu Feb 28 19:09:00 GMT 2019


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536

--- Comment #16 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> 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.

But why would the [0, 1] range hold in the BIT_AND_EXPR case and not in the
BIT_NOT_EXPR case?  Either we take the range as granted in both cases or in
none of them.  If the former, then we can apply the exclusion game in the
BIT_NOT_EXPR case too.


More information about the Gcc-bugs mailing list