[Top][All Lists]

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

Re: [Qemu-devel] clang 3.5.0 errors

From: John Snow
Subject: Re: [Qemu-devel] clang 3.5.0 errors
Date: Wed, 18 Mar 2015 15:22:22 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

On 03/17/2015 07:07 PM, Peter Maydell wrote:
On 17 March 2015 at 19:59, John Snow <address@hidden> wrote:
On 03/17/2015 03:34 PM, Peter Maydell wrote:
On 17 March 2015 at 19:30, John Snow <address@hidden> wrote:
-Wunused-command-line-argument currently complains about the
many include flags passed to each CC incantation

Do you see this with really just --cc=clang ? I see these warnings
if I try to use clang with ccache, but I believe that's a ccache bug.

Not /intentionally/ invoking ccache:

../../configure --cc=clang --host-cc=clang --enable-debug
--extra-cflags="-Werror -Wno-unknown-attributes -Wno-parentheses-equality
-Wno-self-assign -Wno-tautological-compare"

But that's because:

which clang

Which is definitely not of my own doing -- seems to be a default in Fedora

Brave of them :-)

Supposedly this bug is fixed in ccache 3.2:

You can probably work around it by telling QEMU's configure
--extra-cflags=-Qunused-arguments or something similar.

-- PMM

Ah, yes; many of these wind up being ccache problems, but not all of them.

There's one case of error here that's interesting that ccache unearths:

we use a gnu extension to give return values to compound statement blocks, then wrap these blocks into macros as if they were functions.

The practical outcome here is that these blocks have return codes that we often don't check, so clang will spit out "unused value" warnings if we compile these after preprocessing, like ccache will tend to do.

This warning is potentially valid: if these calls can fail, we should probably either be asserting that a failure did not occur OR we should switch to a variant without a return code, if failure is impossible in these locations.

An example of this is in linux-user/elfload.c where we define the NEW_AUX_ENT() macro which in turn uses the put_user_ual(val, sp) macro. When this is expanded, it turns into a compound statement where we discard the expression result, so clang whines.

Of course, this all goes away if you disable ccache, but is it worth adjusting this particular usage anyway?


reply via email to

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