https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768
--- Comment #20 from Danila <flashmozzg at gmail dot com> ---
(In reply to Alexander Monakov from comment #17)
> Right, removing wbnoinvd detection from -march=native would solve the
> reported issue.
>
> (to be honest, I don't see the value in wbnoinvd support in GCC (user-space
> code cannot use it, kernel-space code is not going to use it), and I was
> speaking about completely removing support for it from the compiler)
Grepping kernel source I saw that it defines:
static __always_inline void wbnoinvd(void)
{
/*
* Explicitly encode WBINVD if X86_FEATURE_WBNOINVD is unavailable even
* though WBNOINVD is backwards compatible (it's simply WBINVD with an
* ignored REP prefix), to guarantee that WBNOINVD isn't used if it
* needs to be avoided for any reason. For all supported usage in the
* kernel, WBINVD is functionally a superset of WBNOINVD.
*/
alternative("wbinvd", ASM_WBNOINVD, X86_FEATURE_WBNOINVD);
}
So that explains why it's not an issue for the kernel - even if the task using
wbnoinvd was scheduled on LP-E core it'd still "work" just falling back to
"wbinvd" (according to this comment) instead of crashing with SIGILL.
Still, getting different feature set depending on which core the compiler
happened to run on is annoying and can lead to subtle non-determinism if
nothing else (I caught it when trying to match cached compilations for
llvm-based JIT which failed due cpu features mismatch).
