lkml.org 
[lkml]   [2018]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] sched/fair: Change sched_feat(x) in !CONFIG_SCHED_DEBUG case
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.


\
 
 \ /
  Last update: 2018-04-23 11:46    [W:0.764 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site