Re: [GIT PULL] x86/build changes for v4.17

[Matthias Kaehlcke <mka@chromium.org>]

El Wed, Apr 04, 2018 at 11:30:07AM +0200 Peter Zijlstra ha dit:

> On Tue, Apr 03, 2018 at 11:06:58AM -0700, Matthias Kaehlcke wrote:
> 
> > Yes, Chrome OS R67 (currently dev, soon beta) will ship a kernel built
> > with Clang for multiple x86 Chromebooks.
> 
> But there are still _known_ miscompilations....

Our compiler team is looking into this (missing option
-fno-delete-null-pointer-checks)

So far we didn't encounter any actual issues clearly linked to this,
neither during internal testing nor from devices in the field (some
arm64 devices use a kernel built with clang since R63, some x86
devices shipped with a clang built kernel with R63 and R64). Obviously
there might be latent issues and we are working on fixing the
underlying problem.

> > Given that it takes time for distributions to roll out new compiler
> > versions I would like to ask for a longer period of 'exemption' from
> > asm-goto for Clang, at least if it isn't an actual burden for the
> > kernel, like preventing important features from being added. An ideal
> > time would be after the next-next LTS version, if this is considered
> > too far out, after the next LTS version would be the second best time
> > IMO. Let me be clear, this is *not* to delay the implementation of
> > asm-goto, but to facilitate the use of Clang-built kernels by other
> > projects and distributions, as well as automated builds of upstream
> > kernels with Clang, without requiring necessarily the very latest
> > version of Clang or extra patches.
> 
> I don't think that's sane or realistic, given that the very latest clang
> is _known_ to miscompile the kernel. How can you want to support older
> compilers that are therefore also known to not work correctly.
> 
> Next LTS is still a fair way out, if we take LTS release to be
> every ~5 releases, the next one would be ~.19, that's still 3 releases
> hence. That's a _long_ time.
> 
> I don't see the point in waiting that long for a compiler that doesn't
> work even without asm-goto.

Even with clang having known issues it would be preferable not to
break kernel builds with clang, if this doesn't place a signifcant
burden on the kernel. I'm not sure it is strictly necessary to 'wait'
for clang to enforce asm-goto for gcc (and thus the vast majority of
builds), which is the primary goal of your patch. Couldn't we just
exclude clang for now from raising the error when lack of asm-goto
support is detected?