Messages in this thread | | | Date | Thu, 28 Jul 2016 10:46:24 +0200 | From | Borislav Petkov <> | Subject | Re: [PATCH] Kbuild: Move -Wmaybe-uninitialized to W=1 |
| |
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. --
| |