[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 0/2] Replaced locks with lock guard macros

From: Richard Henderson
Subject: Re: [PATCH v4 0/2] Replaced locks with lock guard macros
Date: Mon, 23 Mar 2020 15:32:38 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

On 3/23/20 2:46 PM, Daniel Brodsky wrote:
> On Mon, Mar 23, 2020 at 6:25 AM Stefan Hajnoczi <address@hidden> wrote:
>> On Fri, Mar 20, 2020 at 06:43:23AM -0700, address@hidden wrote:
>>> /tmp/qemu-test/src/util/thread-pool.c:213:5: error: unused variable 
>>> 'qemu_lockable_auto1' [-Werror,-Wunused-variable]
>>>     QEMU_LOCK_GUARD(&pool->lock);
>>>     ^
>>> /tmp/qemu-test/src/include/qemu/lockable.h:173:29: note: expanded from 
>>> macro 'QEMU_LOCK_GUARD'
>> Apparently gcc suppresses "unused variable" warnings with g_autoptr() so
>> we didn't see this warning before.
>> clang does report them so let's silence the warning manually.  Please
>> add G_GNUC_UNUSED onto the g_autoptr variable definition in the
>> QEMU_LOCK_GUARD() macro:
>>   #define QEMU_LOCK_GUARD(x) \
>>       g_autoptr(QemuLockable) qemu_lockable_auto##__COUNTER__ G_GNUC_UNUSED 
>> = \
>>               qemu_lockable_auto_lock(QEMU_MAKE_LOCKABLE((x)))
>> The WITH_*_LOCK_GUARD() macros should not require changes because the
>> variable is both read and written.
>> You can test locally by building with clang (llvm) instead of gcc:
>>   ./configure --cc=clang
> Using --cc=clang is causing the following error in several different places:
> qemu/target/ppc/translate.c:1894:18: error: result of comparison
> 'target_ulong' (aka 'unsigned int') <= 4294967295
> is always true [-Werror,-Wtautological-type-limit-compare]
>         if (mask <= 0xffffffffu) {
>             ~~~~ ^  ~~~~~~~~~~~
> these errors don't come up when building with gcc. Any idea how to fix
> this? Or should I just suppress it?

I'm of the opinion that it should be suppressed.

This is the *correct* test for ppc64, and the warning for ppc32 is simply
because target_ulong == uint32_t.  True is the correct result for ppc32.

We simply want the compiler to DTRT: simplify this test and remove the else as


reply via email to

[Prev in Thread] Current Thread [Next in Thread]