From mboxrd@z Thu Jan 1 00:00:00 1970 From: peterz@infradead.org (Peter Zijlstra) Date: Mon, 23 Apr 2018 11:45:30 +0200 Subject: [PATCH] sched/fair: Change sched_feat(x) in !CONFIG_SCHED_DEBUG case In-Reply-To: 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> Message-ID: <20180423094530.GW4064@hirez.programming.kicks-ass.net> To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org 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.