[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK8P3a3dC-ZUKMB=V3N67A9xzpLJj7YG9+Oy0OXkfALAwrPiXQ@mail.gmail.com>
Date: Tue, 18 Jul 2017 22:21:37 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Jiri Olsa <jolsa@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Tejun Heo <tj@...nel.org>, Guenter Roeck <linux@...ck-us.net>,
IDE-ML <linux-ide@...r.kernel.org>,
Linux Media Mailing List <linux-media@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
dri-devel <dri-devel@...ts.freedesktop.org>,
Kees Cook <keescook@...omium.org>,
Ingo Molnar <mingo@...nel.org>,
Laura Abbott <labbott@...hat.com>,
Pratyush Anand <panand@...hat.com>
Subject: Re: [PATCH 07/14] proc/kcore: hide a harmless warning
On Tue, Jul 18, 2017 at 10:07 PM, Ard Biesheuvel
<ard.biesheuvel@...aro.org> wrote:
> On 18 July 2017 at 21:01, Arnd Bergmann <arnd@...db.de> wrote:
>> On Tue, Jul 18, 2017 at 9:55 PM, Ard Biesheuvel
>
> Ah, now it makes sense. I was a bit surprised that
> -Wtautological-compare complains about symbolic constants that resolve
> to the same expression, but apparently it doesn't.
>
> I see how ccache needs to preprocess first: that is how it notices
> changes, by hashing the preprocessed input and comparing it to the
> stored hash. I'd still expect it to go back to letting the compiler
> preprocess for the actual build, but apparently it doesn't.
When I tried to figure this out, I saw that ccache has two modes, "direct"
and "preprocessed". It usually tries to use direct mode unless something
prevents that.
In "direct" mode, it hashes the source file and the included headers
instead of the preprocessed source file, however it still calls the compiler
for the preprocessed source file, I guess since it has to preprocess the
file the first time it is seen so it can record which headers are included.
> A quick google search didn't produce anything useful, but I'd expect
> other ccache users to run into the same issue.
I suspect gcc-7 is still too new for most people to have noticed this.
The kernel is a very large codebase, and we only got a handful
of -Wtautological-compare warnings at all, most of them happen
wtihout ccache, too.
Among the four patches, three are for -Wtautological-compare, and one
is for -Wint-in-bool-context:
if (v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, &fmt->fmt.sliced))
v4l2_subdev_call() in this case is a function-like macro that may return
-ENODEV if its first argument is NULL. The other -Wint-in-bool-context
I found all happen with or without ccache, most commonly there is
an constant integer expression passed into a macro and then checked
like
#define macro(arg) \
do { \
if (arg) \
do_something(arg); \
} while (0)
Arnd
Powered by blists - more mailing lists