Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 23 Apr 2018 11:45:30 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     Lukas Bulwahn <lukas.bulwahn@gmail.com>
Cc:     Philipp Klocke <Phil_K97@gmx.de>, kernelnewbies@kernelnewbies.org,
        llvmlinux@lists.linuxfoundation.org, sil2review@lists.osadl.org,
        der.herr@hofr.at, Ingo Molnar <mingo@redhat.com>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sched/fair: Change sched_feat(x) in !CONFIG_SCHED_DEBUG
 case
Message-ID: <20180423094530.GW4064@hirez.programming.kicks-ass.net>
References: <20180416085426.24157-1-Phil_K97@gmx.de>
 <20180420075717.GB4064@hirez.programming.kicks-ass.net>
 <34572fee-36d0-36e1-ba6d-f098b145aba4@gmx.de>
 <20180420165139.GP4064@hirez.programming.kicks-ass.net>
 <alpine.DEB.2.20.1804202303350.17045@alpaca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.20.1804202303350.17045@alpaca>
User-Agent: Mutt/1.9.3 (2018-01-21)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Apr 20, 2018 at 11:29:33PM +0200, Lukas Bulwahn wrote:
> 
> On Fri, 20 Apr 2018, Peter Zijlstra wrote:
> 
> > On Fri, Apr 20, 2018 at 06:29:07PM +0200, Philipp Klocke wrote:
> > > The gain is stopping a warning that clutters the output log of clang.
> > 
> > Well, you should not be using clang anyway. It is known to miscompile
> > the kernel.
> > 
> 
> There are some advantages of having a second compiler that can compile
> the kernel (https://lwn.net/Articles/734071/). Some people in the kernel 
> community and LLVM community are trying to get that to work.

Sure, not arguing against that. Just saying clang isn't there yet and it
has much bigger problems than a stray warning.

> We also want a zero-warning policy for clang, similar to gcc. 
> Hence, this motivates to have a look at those few clang warnings and come 
> up with patches for them.
> 
> This does not imply to make changes at any cost, and we need to determine 
> a proper patch to either change the source code, disable the warning in 
> the build script or annotate the file with some clang-specific pragmas.
> 
> To us, a minor change in the source sounded most reasonable after looking
> at all three possible patches. Philipp might need another iteration, but
> it generally looks sound to me if we get the details flattened out. 

Given the history of compiler warnings; I would really like to have some
text that explains why the warning is useful and should be worked
around.

To me the warning under discussion seems very dodgy and I would propose
to disable it entirely. Using a value other than 0/1 for boolean
expressions is fairly common, it being a compile time constant doesn't
seem to make much difference to me.