Re: [PATCH] sched/fair: Change sched_feat(x) in !CONFIG_SCHED_DEBUG case
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. 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. Lukas
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.
participants (2)
-
Lukas Bulwahn -
Peter Zijlstra