* Ingo Molnar <mingo@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
