Re: [PATCH] Kbuild: Move -Wmaybe-uninitialized to W=1

[Borislav Petkov <bp@alien8.de>]

On Thu, Jul 28, 2016 at 10:29:15AM +0200, Ingo Molnar wrote:
> BUT, isn't this the natural state of things, that the 'final' warnings
> that don't get fixed are the obnoxious, false positive ones - because
> anyone who looks at them will say "oh crap, idiotic compiler!"?

Hmm, so my experience is like Linus' - that -Wmaybe thing generates too
much noise and a lot of false positives. The thing is, as Micha (on CC)
explained it to me, that warning simply says that GCC sometimes *cannot*
know whether the variable will be used uninitialized or not and eagerly
issues the warning message, just in case.

> But over the last couple of years I think we probably had hundreds of
> bugs avoided due to the warning (both at the development and at the
> integration stage) - and

Really?

And I've yet to see an example where it actually helped :-\

>   commit e01d8718de4170373cd7fbf5cf6f9cb61cebb1e9
>   Author: Peter Zijlstra <peterz@infradead.org>
>   Date:   Wed Jan 27 23:24:29 2016 +0100
> 
>     perf/x86: Fix uninitialized value usage
> 
>   ...
> 
>   Only took 6 hours of painful debugging to find this. Neither GCC nor
>   Smatch warnings flagged this bug.

So that warning didn't help here either.

> ... and my worry here is that we are now telling GCC: "don't you dare
> generate a false positive warning!" - at which point GCC folks will
> add even MORE heuristics to avoid false positives that generate even
> more false negatives

Why?

I think we should enable only the real warnings and turn off the stuff
which generates a lot of false positives. Or, we could put them behind
the -W= switch, so that people can still build the kernel with it but
not have them enabled by default.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--