From: peterz@infradead.org (Peter Zijlstra)
To: kernelnewbies@lists.kernelnewbies.org
Subject: [PATCH] sched/fair: Change sched_feat(x) in !CONFIG_SCHED_DEBUG case
Date: Mon, 23 Apr 2018 11:45:30 +0200 [thread overview]
Message-ID: <20180423094530.GW4064@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <alpine.DEB.2.20.1804202303350.17045@alpaca>
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.
next prev parent reply other threads:[~2018-04-23 9:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180416085426.24157-1-Phil_K97@gmx.de>
2018-04-18 13:49 ` [PATCH] sched/fair: Change sched_feat(x) in !CONFIG_SCHED_DEBUG case Nicholas Mc Guire
2018-04-20 7:57 ` Peter Zijlstra
2018-04-20 16:29 ` Philipp Klocke
2018-04-20 16:51 ` Peter Zijlstra
2018-04-20 21:29 ` Lukas Bulwahn
2018-04-23 9:45 ` Peter Zijlstra [this message]
2018-04-20 10:34 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180423094530.GW4064@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=kernelnewbies@lists.kernelnewbies.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).