https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98737
--- Comment #8 from Ulrich Drepper <drepper.fsp+rhbz at gmail dot com> ---
(In reply to Jakub Jelinek from comment #7)
> The sub fix won't be the same as would add, perhaps xor/or/and can be
> handled by the same peephole2, but even for that I'm not sure.
Just a proposal, but I can see myself using code like this.
> Though e.g.
> trying __atomic_or_fetch (&a, b, ...) == 0 doesn't seem to be something
> people would use.
I can see this being valid. If b is a variable of some time (e.g.,
representing a flag), a could be the set of all flag set and the result of the
or operation being non-zero could mean some work based on the flags needs to be
done.
The alternative is is
if ((b != 0 && __atomic_or_fetch(&a, b, ...)) || a != 0)
...
Unconditionally performing the or is likely faster than the additional tests
and jumps.
