Re: Compile problems w/gcc 9.4.0 in linux-next

[Ard Biesheuvel <ardb@kernel.org>]

Hi Michael,

On Thu, 20 Mar 2025 at 19:29, Michael Kelley <mhklinux@outlook.com> wrote:
>
> Brian/Ingo/Ard -
>
> I'm seeing a compile problem in linux-next-20250319 with gcc 9.4.0. I've bisected
> to a group of 6 commits that you authored:
>
> a9a76b38aaf5 x86/boot: Disable stack protector for early boot code
> f58b63857ae3 x86/pvh: Use fixed_percpu_data for early boot GSBASE
> cb7927fda002 x86/relocs: Handle R_X86_64_REX_GOTPCRELX relocations
> 78c4374ef8b8 x86/module: Deal with GOT based stack cookie load on Clang < 17
> 80d47defddc0 x86/stackprotector/64: Convert to normal per-CPU variable
> 9d7de2aa8b41 x86/percpu/64: Use relative percpu offsets
>
> As of a9a76b38aaf5, everything compiles correctly.
>
> For f58b63857ae3 thru 80d47defddc0, this error occurs:
>
>     arch/x86/platform/pvh/head.S: Assembler messages:
>     arch/x86/platform/pvh/head.S:183: Error: operand size mismatch for `movq'
>

This is simply a bug in patch f58b63857ae3, which uses movq on
EDX/EAX. This breaks bisection (as you've noticed), annoyingly, and
I'll leave it to the tip maintainers to decide whether this warrants a
rebase (given that the fix is already queued up as well)

> As of 9d7de2aa8b41 and later, the head.S error goes away, and this
> error occurs:
>
>     lib/zstd/compress/huf_compress.c:1033:1: internal compiler error: Segmentation fault
>      1033 | {
>           | ^
>     Please submit a full bug report,
>     with preprocessed source if appropriate.
>     See <file:///usr/share/doc/gcc-9/README.Bugs> for instructions.
>
> Interestingly, if DYNAMIC_BMI2 in lib/zstd/common/portability_macros.h
> is changed on line 61 to always be defined as 0, the compile problem in
> huf_compress.c goes away.
>

Without having looked at the crashing code, I suspect that the only
meaningful course of action here is to tweak the conditional logic
that defines DYNAMIC_BMI2 to only enable it for GCC >= 10.1 (assuming
those are unaffected) In any case, GCC 9.4 is not going to get fixed
in the field, so even if this gets fixed on the GCC side, we will have
to deal with it here.

> I'm using gcc 9.4.0 in an Ubuntu 20.04 install as it's the standard compiler
> for that version of Ubuntu. I'm guessing that getting a fix for that
> relatively old version of gcc isn't likely. I have not tested with other
> gcc versions.