From: John Snow <jsnow@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-devel <qemu-devel@nongnu.org>,
Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] clang 3.5.0 errors
Date: Wed, 18 Mar 2015 15:22:22 -0400 [thread overview]
Message-ID: <5509D06E.4060507@redhat.com> (raw)
In-Reply-To: <CAFEAcA_w1Z9_YDnBBWErRf0MDxoqG2Bg=UEAuAk=0SSucaZapA@mail.gmail.com>
On 03/17/2015 07:07 PM, Peter Maydell wrote:
> On 17 March 2015 at 19:59, John Snow <jsnow@redhat.com> wrote:
>> On 03/17/2015 03:34 PM, Peter Maydell wrote:
>>> On 17 March 2015 at 19:30, John Snow <jsnow@redhat.com> 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
>> /usr/lib64/ccache/clang
>>
>> Which is definitely not of my own doing -- seems to be a default in Fedora
>> 21.
>
> Brave of them :-)
>
> Supposedly this bug is fixed in ccache 3.2:
> https://bugzilla.samba.org/show_bug.cgi?id=8118
>
> 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?
--js
next prev parent reply other threads:[~2015-03-18 19:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-17 19:30 [Qemu-devel] clang 3.5.0 errors John Snow
2015-03-17 19:34 ` Peter Maydell
2015-03-17 19:59 ` John Snow
2015-03-17 23:07 ` Peter Maydell
2015-03-18 19:22 ` John Snow [this message]
2015-03-18 20:28 ` Peter Maydell
2015-03-18 22:22 ` John Snow
2015-03-18 22:48 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5509D06E.4060507@redhat.com \
--to=jsnow@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).