Comment 2 for bug 1881004

On 5/27/20 4:40 PM, Peter Maydell wrote:
> On Wed, 27 May 2020 at 20:21, Philippe Mathieu-Daudé
> <email address hidden> wrote:
>>
>> Public bug reported:
>>
>> Last time I built QEMU was on commit d5c75ec500d96f1d93447f990cd5a4ef5ba27fae,
>> I just pulled to fea8f3ed739536fca027cf56af7f5576f37ef9cd and now get:
>>
>> CC lm32-softmmu/fpu/softfloat.o
>> fpu/softfloat.c:3365:13: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation]
>> absZ &= ~ ( ( ( roundBits ^ 0x40 ) == 0 ) & roundNearestEven );
>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> !
>
>
> "(x & y)" is not a boolean expression, so we should report this to clang
> as a bug (I assume what they actually are trying to complain about is
> bitwise AND with a boolean expression).

We have:

uint64_t &= ~ ( ( ( int8_t ^ int ) == int ) & bool )

which is

uint64_t &= ~ ( bool & bool )

which is then

uint64_t &= ~ ( int )

resulting in one of:

uint64_t &= 0xffffffffffffffff
uint64_t &= 0xfffffffffffffffe

It is a very odd way of stating that 'if this condition is true, mask
out the least-significant-bit'. In general, 'bool & bool' is used where
the side-effect-skipping 'bool && bool' is inappropriate; I'm a bit
surprised that clang is not questioning whether we meant '&&' instead of
'&' (the two operators give the same effect in this case).

You are right that clang is fishy for calling it logical negation of a
bool, when it is really logical negation of an int, but we are also
fishy in that we are using bitwise AND of two bools as an int in the
first place.

Regardless of whether clang changes, would it be better to write the
code as:

if (((roundBits ^ 0x40) == 0) && roundNearestEven) {
     absZ &= ~1;
}

--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org