On 7/4/2026 9:44 AM, Andrew Pinski wrote:
> Turns out it was easy to fix these patterns for
> `--param=logical-op-non-short-circuit=0` case after all.
> Just add support for `((a ^ b) & c) cmp d && a == b`
> which is the same as `!(((a ^ b) & c) cmp d || a != b)`.
> So this adds the bit_and case to support exactly that.
> Also fixes up some of the `:c` on the operands.
> `:c` needs to be on the outer bitop and does not need to be
> on the inner one for bit_xor as it will be the same order as ne/eq.
>
> gcc/ChangeLog:
>
> * match.pd (`((a ^ b) & c) cmp d || a != b`): Expand
> to support bit_and and fix up the :c.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/tree-ssa/fold-xor-and-or-1.c: New test.
> * gcc.dg/tree-ssa/fold-xor-or-1.c: New test.
> * gcc.dg/tree-ssa/pr102793-1.c: Update for the optimization
> happening in pre.
But for
`((a ^ b) & c) cmp d && a == b`
When that "a == b" term is true, then the "a ^ b" term will be 0, thus
(a ^ b) & 0 is also zero. So isn't the simplification to
0 cmp d && a == b?
Or did I miss something?
jeff