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 )
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:
On 5/27/20 4:40 PM, Peter Maydell wrote: d93447f990cd5a4 ef5ba27fae, ca027cf56af7f55 76f37ef9cd and now get: fpu/softfloat. o c:3365: 13: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror, -Wbool- operation] ~~~~~~~ ~~~~~~~ ~~~~~~~ ~~~~~~~ ~~~~~~~ ~~~~~~~ ~~~~~
> 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 d5c75ec500d96f1
>> I just pulled to fea8f3ed739536f
>>
>> CC lm32-softmmu/
>> fpu/softfloat.
>> 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 nt-bit' . In general, 'bool & bool' is used where skipping 'bool && bool' is inappropriate; I'm a bit
out the least-significa
the side-effect-
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