Re: [PATCH] x86/build/64: Prevent native builds from generating SSE/AVX code

[Nathan Chancellor]

On Sun, Oct 25, 2026 at 09:07:35PM +0100, Antoni Kuczyński wrote:
> On Sun, Oct 25, 2026 at 12:44:11PM -0700, Nathan Chancellor wrote:
> > This option has been in the kernel for quite some time and I am sure
> > people are using it. I wonder why this has not come up sooner. Just
> > unlucky timing or configuration?
> 
> Configuration, on my side, sorry for the noise. Following up on your
> question I found that "gcc" in my PATH was the icecc (icecream 1.4.0)
> wrapper. To be able to distribute the compilation, icecc replaces
> -march=native with an explicit list of options for the local CPU:
> 
>   /usr/bin/gcc -mno-sse -mno-avx -Os -march=ivybridge -mmmx -mpopcnt
>     -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx ...
> 
> so the expanded -msse/-mavx come after the kernel's -mno-* flags and
> win. Plain GCC 14.2 does not have this problem: the reproducer from
> the changelog built with /usr/bin/gcc-14 emits no SIMD instructions,
> as explicit -mno-* options take precedence over what -march=native
> enables.
> 
> So the changelog's explanation and the Fixes:/stable tags are wrong,
> please drop this patch. I will report the issue to icecream instead.

Ah yeah, that makes a lot more sense. I guess the easiest solution is
probably something like this patch internally where the expanded value
of '-march=native' is moved to the front of the GCC command so that any
overrides can happen naturally.

> > Maintaining two copies of these flags (and having them appear in the
> > command line twice) seems objectively worse than just adding an extra
> > 'ifdef CONFIG_X86_64' and moving the block up so that this happens in
> > the naturally expected order?
> 
> Agreed, and FWIW your diff on top of current master also fixes the
> icecc build here: -march=native now comes before the -mno-* flags and
> arch/x86/boot/startup/gdt_idt.o contains no SIMD instructions. If you
> think that ordering is worth having on its own merits, I am happy to
> send it as a cleanup without Fixes:/stable, but I understand if it is
> not worth the churn for an icecc-only problem.

I guess that is up to the x86 maintainers. I would personally be fine
with it since the workaround is basically an extra ifdef and comment,
which I do not see an substantial maintenance burden, but they might
feel otherwise.

-- 
Cheers,
Nathan