From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757534AbcG1TDv (ORCPT ); Thu, 28 Jul 2016 15:03:51 -0400 Received: from mail-oi0-f43.google.com ([209.85.218.43]:33740 "EHLO mail-oi0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754969AbcG1TDr (ORCPT ); Thu, 28 Jul 2016 15:03:47 -0400 MIME-Version: 1.0 In-Reply-To: <20160728082915.GA2349@gmail.com> References: <20140616132045.GE8170@pd.tnic> <20140616211405.GA7914@ravnborg.org> <20140624213835.GD15068@pd.tnic> <20140707105339.GA4776@pd.tnic> <20160728042011.GA25498@nazgul.tnic> <20160728082915.GA2349@gmail.com> From: Linus Torvalds Date: Thu, 28 Jul 2016 12:03:45 -0700 X-Google-Sender-Auth: M8OFVK-UdAUMn29TjPePLV8g5rQ Message-ID: Subject: Re: [PATCH] Kbuild: Move -Wmaybe-uninitialized to W=1 To: Ingo Molnar Cc: Borislav Petkov , Sam Ravnborg , lkml , Michael Matz , Linux Kbuild mailing list , x86-ml Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 28, 2016 at 1:29 AM, Ingo Molnar wrote: > > > So I'm worried about this description in the changelog: > > | Looking at the warnings produced, every single one I looked at was a false > | positive, and the warnings are frequent enough (and big enough) that they can > | easily hide real problems that you don't notice in the noise generated by > | -Wmaybe-uninitialized. > > 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!"? No. The *natural* state of things is very simple: Zero warnings. End of story. No excuses. We were there at 4.6 for me with an "allmodconfig" build. In 4.7, we had over a hundred lines of warnings. That is SIMPLY UNACCEPTABLE. And the new warnings were actually not so much due to new code in 4.7, as the fact that in between I did a user-space upgrade, and gcc 6.1.1 has regressed to the point of the warnings being an unusable mess. > 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 > now we are upset about a dozen residual warnings and declare it's all crap? Nobody fixed the warnings, and looking at them, they were largely unfixable without making the code worse. Complain to the gcc people. Remember: zero warnings. > I am happy to bash GCC's cavalier attitude to warnings any day of the week, but > this argumentation for this particular option looks fishy to me. It has nothing to do with "that particular option". It has everything to do with bad warnings in general. Also, if you actually look at the patch, you'll see that that option has already been disabled for a _lot_ of configurations because it was already bad for most cases. > Why cannot we say something like: > > "a false_positive/false_negative ratio above 10% is considered obnoxious and > won't be tolerated." Sure. I'm happy to do that. What part of "100% of all the warnings were false positives, and won't be tolerated" did you not get? Once we get to the point that the warning is no longer useful, and is more pain than gain, it gets disabled. If you open a bugzilla and the gcc people actually react to it, we can revisit it. But as it is, that warning had largely been disabled for other configurations anyway, and I just made it go away entirely. Because false positives that we can't fix without making the code worse are not acceptable. Linus