[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160728170413.GA15229@gmail.com>
Date: Thu, 28 Jul 2016 19:04:13 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Borislav Petkov <bp@...en8.de>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Sam Ravnborg <sam@...nborg.org>,
lkml <linux-kernel@...r.kernel.org>, Michael Matz <matz@...e.de>,
linux-kbuild@...r.kernel.org, x86-ml <x86@...nel.org>,
Arnaldo Carvalho de Melo <acme@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH] Kbuild: Move -Wmaybe-uninitialized to W=1
* Ingo Molnar <mingo@...nel.org> wrote:
> But that's my point, I believe the false positive rate is pretty low in fact, due
> to three factors:
>
> - 90% of the warnings get fixed by developers, we never see them upstream
>
> - I'd say a majority (say 70%) of the remaining warnings are flagging 'complexity
> bugs'
>
> - only a residual 3% are obnoxious ones.
>
> But these remaining 3% are the ones we are seeing again and again in various
> compiler output, so we tend to get a subjective impression that this warning
> produces countless false positives.
And note that I am well aware of the real risk this poses: people will ignore real
warnings if there are so many residual false positives.
I think this approach worked pretty well for perf:
> So I *think* the better option would be to do what we are doing in the perf
> tooling: force a build error for these warnings (by default, with an option
> available to make it build). That flushes them out and also makes it sure that
> those questionable sequences of code never get upstream to begin with.
... but might not be appropriate for the kernel which is a 2 orders of magnitude
larger code base.
Thanks,
Ingo
Powered by blists - more mailing lists