Compile problems w/gcc 9.4.0 in linux-next

Compile problems w/gcc 9.4.0 in linux-next

[Michael Kelley]

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'

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.

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.

Thoughts on how to proceed? 

Michael Kelley 

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

[Ard Biesheuvel]

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.

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

[Michael Kelley]

From: Ard Biesheuvel <ardb@kernel.org> Sent: Thursday, March 20, 2025 12:20 PM
> 
> 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.

Nick and David --

What are your thoughts as maintainers of lib/zstd?

Michael

> 
> > 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.

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

[Michael Kelley]

From: Michael Kelley <mhklinux@outlook.com> Sent: Thursday, March 20, 2025 1:42 PM
> 
> From: Ard Biesheuvel <ardb@kernel.org> Sent: Thursday, March 20, 2025 12:20 PM
> >
> > 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.
> 
> Nick and David --
> 
> What are your thoughts as maintainers of lib/zstd?
> 

FYI, the same segfault occurs with gcc 10.5. The problem is fixed
in gcc 11.4.

Michael

> 
> >
> > > 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.

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

[Ingo Molnar]

* Michael Kelley <mhklinux@outlook.com> wrote:

> > What are your thoughts as maintainers of lib/zstd?
> 
> FYI, the same segfault occurs with gcc 10.5. The problem is fixed
> in gcc 11.4.

So the patch below would work this around on GCC9 and GCC10?

Thanks,

	Ingo

==============>
 lib/zstd/common/portability_macros.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/zstd/common/portability_macros.h b/lib/zstd/common/portability_macros.h
index 0e3b2c0a527d..0dde8bf56595 100644
--- a/lib/zstd/common/portability_macros.h
+++ b/lib/zstd/common/portability_macros.h
@@ -55,7 +55,7 @@
 #ifndef DYNAMIC_BMI2
   #if ((defined(__clang__) && __has_attribute(__target__)) \
       || (defined(__GNUC__) \
-          && (__GNUC__ >= 5 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8)))) \
+          && (__GNUC__ >= 11))) \
       && (defined(__x86_64__) || defined(_M_X64)) \
       && !defined(__BMI2__)
   #  define DYNAMIC_BMI2 1

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

[Michael Kelley]

From: Ingo Molnar <mingo@kernel.org> Sent: Friday, March 21, 2025 12:38 AM
> 
> * Michael Kelley <mhklinux@outlook.com> wrote:
> 
> > > What are your thoughts as maintainers of lib/zstd?
> >
> > FYI, the same segfault occurs with gcc 10.5. The problem is fixed
> > in gcc 11.4.
> 
> So the patch below would work this around on GCC9 and GCC10?

I've confirmed that the patch gives a clean compile with gcc 9.4.

Note that I confirmed yesterday that the gcc problem is fixed with
11.4. I don't know about earlier gcc 11 minor versions. Lemme see
if I can get the original gcc 11 release and try that to confirm that
your patch has the right version cutoff.

Michael  

> 
> Thanks,
> 
> 	Ingo
> 
> ==============>
>  lib/zstd/common/portability_macros.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/zstd/common/portability_macros.h b/lib/zstd/common/portability_macros.h
> index 0e3b2c0a527d..0dde8bf56595 100644
> --- a/lib/zstd/common/portability_macros.h
> +++ b/lib/zstd/common/portability_macros.h
> @@ -55,7 +55,7 @@
>  #ifndef DYNAMIC_BMI2
>    #if ((defined(__clang__) && __has_attribute(__target__)) \
>        || (defined(__GNUC__) \
> -          && (__GNUC__ >= 5 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8)))) \
> +          && (__GNUC__ >= 11))) \
>        && (defined(__x86_64__) || defined(_M_X64)) \
>        && !defined(__BMI2__)
>    #  define DYNAMIC_BMI2 1

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

[Nick Terrell]

> On Mar 21, 2025, at 8:16 AM, Michael Kelley <mhklinux@outlook.com> wrote:
> 
> > 
> From: Ingo Molnar <mingo@kernel.org> Sent: Friday, March 21, 2025 12:38 AM
>> 
>> * Michael Kelley <mhklinux@outlook.com> wrote:
>> 
>>>> What are your thoughts as maintainers of lib/zstd?
>>> 
>>> FYI, the same segfault occurs with gcc 10.5. The problem is fixed
>>> in gcc 11.4.
>> 
>> So the patch below would work this around on GCC9 and GCC10?
> 
> I've confirmed that the patch gives a clean compile with gcc 9.4.
> 
> Note that I confirmed yesterday that the gcc problem is fixed with
> 11.4. I don't know about earlier gcc 11 minor versions. Lemme see
> if I can get the original gcc 11 release and try that to confirm that
> your patch has the right version cutoff.

Thanks for the report & proposed fix!

If you can test gcc-11.0, that would be great, otherwise we could just
cut off at (__GNUC__ >= 12 || (__GNUC__ == 11 && __GNUC_MINOR__ >= 4))

I am preparing the zstd-v1.5.7 update, and I will pull a patch that fixes this into my tree.
If someone wants to submit a patch I'll pull that, otherwise I can submit one later today.

Best,
Nick Terrell

> Michael  
> 
>> 
>> Thanks,
>> 
>> Ingo
>> 
>> ==============>
>> lib/zstd/common/portability_macros.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/lib/zstd/common/portability_macros.h b/lib/zstd/common/portability_macros.h
>> index 0e3b2c0a527d..0dde8bf56595 100644
>> --- a/lib/zstd/common/portability_macros.h
>> +++ b/lib/zstd/common/portability_macros.h
>> @@ -55,7 +55,7 @@
>> #ifndef DYNAMIC_BMI2
>>   #if ((defined(__clang__) && __has_attribute(__target__)) \
>>       || (defined(__GNUC__) \
>> -          && (__GNUC__ >= 5 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8)))) \
>> +          && (__GNUC__ >= 11))) \
>>       && (defined(__x86_64__) || defined(_M_X64)) \
>>       && !defined(__BMI2__)
>>   #  define DYNAMIC_BMI2 1
> 

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

[Ingo Molnar]

* Nick Terrell <terrelln@meta.com> wrote:

> 
> 
> > On Mar 21, 2025, at 8:16 AM, Michael Kelley <mhklinux@outlook.com> wrote:
> > 
> > > 
> > From: Ingo Molnar <mingo@kernel.org> Sent: Friday, March 21, 2025 12:38 AM
> >> 
> >> * Michael Kelley <mhklinux@outlook.com> wrote:
> >> 
> >>>> What are your thoughts as maintainers of lib/zstd?
> >>> 
> >>> FYI, the same segfault occurs with gcc 10.5. The problem is fixed
> >>> in gcc 11.4.
> >> 
> >> So the patch below would work this around on GCC9 and GCC10?
> > 
> > I've confirmed that the patch gives a clean compile with gcc 9.4.
> > 
> > Note that I confirmed yesterday that the gcc problem is fixed with
> > 11.4. I don't know about earlier gcc 11 minor versions. Lemme see
> > if I can get the original gcc 11 release and try that to confirm that
> > your patch has the right version cutoff.
> 
> Thanks for the report & proposed fix!
> 
> If you can test gcc-11.0, that would be great, otherwise we could just
> cut off at (__GNUC__ >= 12 || (__GNUC__ == 11 && __GNUC_MINOR__ >= 4))
> 
> I am preparing the zstd-v1.5.7 update, and I will pull a patch that 
> fixes this into my tree. If someone wants to submit a patch I'll pull 
> that, otherwise I can submit one later today.

The proper cutoff would be GCC 11.1, not 11.4, as per the testing of 
Michael Kelley, right?

Thanks,

	Ingo

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

[Nick Terrell]

> On Mar 25, 2025, at 6:18 AM, Ingo Molnar <mingo@kernel.org> wrote:
> 
> > 
> 
> * Nick Terrell <terrelln@meta.com> wrote:
> 
>> 
>> 
>>> On Mar 21, 2025, at 8:16 AM, Michael Kelley <mhklinux@outlook.com> wrote:
>>> 
>>>> 
>>> From: Ingo Molnar <mingo@kernel.org> Sent: Friday, March 21, 2025 12:38 AM
>>>> 
>>>> * Michael Kelley <mhklinux@outlook.com> wrote:
>>>> 
>>>>>> What are your thoughts as maintainers of lib/zstd?
>>>>> 
>>>>> FYI, the same segfault occurs with gcc 10.5. The problem is fixed
>>>>> in gcc 11.4.
>>>> 
>>>> So the patch below would work this around on GCC9 and GCC10?
>>> 
>>> I've confirmed that the patch gives a clean compile with gcc 9.4.
>>> 
>>> Note that I confirmed yesterday that the gcc problem is fixed with
>>> 11.4. I don't know about earlier gcc 11 minor versions. Lemme see
>>> if I can get the original gcc 11 release and try that to confirm that
>>> your patch has the right version cutoff.
>> 
>> Thanks for the report & proposed fix!
>> 
>> If you can test gcc-11.0, that would be great, otherwise we could just
>> cut off at (__GNUC__ >= 12 || (__GNUC__ == 11 && __GNUC_MINOR__ >= 4))
>> 
>> I am preparing the zstd-v1.5.7 update, and I will pull a patch that 
>> fixes this into my tree. If someone wants to submit a patch I'll pull 
>> that, otherwise I can submit one later today.
> 
> The proper cutoff would be GCC 11.1, not 11.4, as per the testing of 
> Michael Kelley, right?

Sorry, I didn't quite realize that the [tip: x86/core] was a commit. I'll drop
my patch, and just make sure that the fix is preserved in the zstd-v1.5.7
upgrade.

Best,
Nick Terrell

> Thanks,
> 
> Ingo

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

[Ingo Molnar]

* Nick Terrell <terrelln@meta.com> wrote:

> 
> 
> > On Mar 25, 2025, at 6:18 AM, Ingo Molnar <mingo@kernel.org> wrote:
> > 
> > > 
> > 
> > * Nick Terrell <terrelln@meta.com> wrote:
> > 
> >> 
> >> 
> >>> On Mar 21, 2025, at 8:16 AM, Michael Kelley <mhklinux@outlook.com> wrote:
> >>> 
> >>>> 
> >>> From: Ingo Molnar <mingo@kernel.org> Sent: Friday, March 21, 2025 12:38 AM
> >>>> 
> >>>> * Michael Kelley <mhklinux@outlook.com> wrote:
> >>>> 
> >>>>>> What are your thoughts as maintainers of lib/zstd?
> >>>>> 
> >>>>> FYI, the same segfault occurs with gcc 10.5. The problem is fixed
> >>>>> in gcc 11.4.
> >>>> 
> >>>> So the patch below would work this around on GCC9 and GCC10?
> >>> 
> >>> I've confirmed that the patch gives a clean compile with gcc 9.4.
> >>> 
> >>> Note that I confirmed yesterday that the gcc problem is fixed with
> >>> 11.4. I don't know about earlier gcc 11 minor versions. Lemme see
> >>> if I can get the original gcc 11 release and try that to confirm that
> >>> your patch has the right version cutoff.
> >> 
> >> Thanks for the report & proposed fix!
> >> 
> >> If you can test gcc-11.0, that would be great, otherwise we could just
> >> cut off at (__GNUC__ >= 12 || (__GNUC__ == 11 && __GNUC_MINOR__ >= 4))
> >> 
> >> I am preparing the zstd-v1.5.7 update, and I will pull a patch that 
> >> fixes this into my tree. If someone wants to submit a patch I'll pull 
> >> that, otherwise I can submit one later today.
> > 
> > The proper cutoff would be GCC 11.1, not 11.4, as per the testing of 
> > Michael Kelley, right?
> 
> Sorry, I didn't quite realize that the [tip: x86/core] was a commit. I'll drop
> my patch, and just make sure that the fix is preserved in the zstd-v1.5.7
> upgrade.

Yeah, the segfault triggered due to changes in the x86 tree, so the fix 
(workaround) is now upstream, but I think the cutoff is overly 
conservative:

  1400c87e6cac ("zstd: Increase DYNAMIC_BMI2 GCC version cutoff from 4.8 to 11.0 to work around compiler segfault")

So it might be a good idea to follow it up with your improved cutoff 
patch, as a delta patch on top? That doesn't have any urgency that I 
can see, so it can go through your tree, or any other path you'd 
prefer!

Thanks,

	Ingo

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

[Ingo Molnar]

* Michael Kelley <mhklinux@outlook.com> wrote:

> From: Ingo Molnar <mingo@kernel.org> Sent: Friday, March 21, 2025 12:38 AM
> > 
> > * Michael Kelley <mhklinux@outlook.com> wrote:
> > 
> > > > What are your thoughts as maintainers of lib/zstd?
> > >
> > > FYI, the same segfault occurs with gcc 10.5. The problem is fixed
> > > in gcc 11.4.
> > 
> > So the patch below would work this around on GCC9 and GCC10?
> 
> I've confirmed that the patch gives a clean compile with gcc 9.4.
> 
> Note that I confirmed yesterday that the gcc problem is fixed with
> 11.4. I don't know about earlier gcc 11 minor versions. Lemme see
> if I can get the original gcc 11 release and try that to confirm that
> your patch has the right version cutoff.

Thank you for the testing!

> > +++ b/lib/zstd/common/portability_macros.h
> > @@ -55,7 +55,7 @@
> >  #ifndef DYNAMIC_BMI2
> >    #if ((defined(__clang__) && __has_attribute(__target__)) \
> >        || (defined(__GNUC__) \
> > -          && (__GNUC__ >= 5 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8)))) \
> > +          && (__GNUC__ >= 11))) \
> >        && (defined(__x86_64__) || defined(_M_X64)) \
> >        && !defined(__BMI2__)
> >    #  define DYNAMIC_BMI2 1

Worst case, if it isn't, I suppose we'll get followup bug reports.

Thanks,

	Ingo

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

[Nick Terrell]

> On Mar 22, 2025, at 12:36 AM, Ingo Molnar <mingo@kernel.org> wrote:
> 
> > 
> 
> * Michael Kelley <mhklinux@outlook.com> wrote:
> 
>> From: Ingo Molnar <mingo@kernel.org> Sent: Friday, March 21, 2025 12:38 AM
>>> 
>>> * Michael Kelley <mhklinux@outlook.com> wrote:
>>> 
>>>>> What are your thoughts as maintainers of lib/zstd?
>>>> 
>>>> FYI, the same segfault occurs with gcc 10.5. The problem is fixed
>>>> in gcc 11.4.
>>> 
>>> So the patch below would work this around on GCC9 and GCC10?
>> 
>> I've confirmed that the patch gives a clean compile with gcc 9.4.
>> 
>> Note that I confirmed yesterday that the gcc problem is fixed with
>> 11.4. I don't know about earlier gcc 11 minor versions. Lemme see
>> if I can get the original gcc 11 release and try that to confirm that
>> your patch has the right version cutoff.
> 
> Thank you for the testing!

I've submitted that patch here:

https://lore.kernel.org/lkml/20250323050749.165863-1-nickrterrell@gmail.com/

I've merged it into my linux-next branch as well.

Best,
Nick Terrell

>>> +++ b/lib/zstd/common/portability_macros.h
>>> @@ -55,7 +55,7 @@
>>> #ifndef DYNAMIC_BMI2
>>>   #if ((defined(__clang__) && __has_attribute(__target__)) \
>>>       || (defined(__GNUC__) \
>>> -          && (__GNUC__ >= 5 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8)))) \
>>> +          && (__GNUC__ >= 11))) \
>>>       && (defined(__x86_64__) || defined(_M_X64)) \
>>>       && !defined(__BMI2__)
>>>   #  define DYNAMIC_BMI2 1
> 
> Worst case, if it isn't, I suppose we'll get followup bug reports.
> 
> Thanks,
> 
> Ingo

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

[Michael Kelley]

From: Nick Terrell <terrelln@meta.com> Sent: Saturday, March 22, 2025 9:58 PM
> 
> > On Mar 22, 2025, at 12:36 AM, Ingo Molnar <mingo@kernel.org> wrote:
> > 
> > * Michael Kelley <mhklinux@outlook.com> wrote:
> >
> >> From: Ingo Molnar <mingo@kernel.org> Sent: Friday, March 21, 2025 12:38 AM
> >>>
> >>> * Michael Kelley <mhklinux@outlook.com> wrote:
> >>>
> >>>>> What are your thoughts as maintainers of lib/zstd?
> >>>>
> >>>> FYI, the same segfault occurs with gcc 10.5. The problem is fixed
> >>>> in gcc 11.4.
> >>>
> >>> So the patch below would work this around on GCC9 and GCC10?
> >>
> >> I've confirmed that the patch gives a clean compile with gcc 9.4.
> >>
> >> Note that I confirmed yesterday that the gcc problem is fixed with
> >> 11.4. I don't know about earlier gcc 11 minor versions. Lemme see
> >> if I can get the original gcc 11 release and try that to confirm that
> >> your patch has the right version cutoff.

After a bunch of manual wrangling, I finally got gcc-11.1.0-1 installed
alongside gcc-9.4.0 in a clean Ubuntu 20.04 VM. As expected,
building linux-next-20250321 with gcc-9.4.0 fails.  And building with
gcc-11.1.0-1 compiles with no problems, and the resulting kernel
runs correctly.

gcc-11.1.0-1 is the earliest 11.x version I can find. It's from the
Debian repo archives. Interestingly, gcc-11.1.0-1 also requires
binutils 2.35.2-2 (it fails with 2.34), so I had to manually install those
packages as well. But 11.4.0 works fine with binutils 2.34, so maybe
they downgraded the requirements at some point in the minor
update stream.

Michael

> >
> > Thank you for the testing!
> 
> I've submitted that patch here:
> 
> https://lore.kernel.org/lkml/20250323050749.165863-1-nickrterrell@gmail.com/
> 
> I've merged it into my linux-next branch as well.
> 
> Best,
> Nick Terrell
> 
> >>> +++ b/lib/zstd/common/portability_macros.h
> >>> @@ -55,7 +55,7 @@
> >>> #ifndef DYNAMIC_BMI2
> >>>   #if ((defined(__clang__) && __has_attribute(__target__)) \
> >>>       || (defined(__GNUC__) \
> >>> -          && (__GNUC__ >= 5 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8)))) \
> >>> +          && (__GNUC__ >= 11))) \
> >>>       && (defined(__x86_64__) || defined(_M_X64)) \
> >>>       && !defined(__BMI2__)
> >>>   #  define DYNAMIC_BMI2 1
> >
> > Worst case, if it isn't, I suppose we'll get followup bug reports.
> >
> > Thanks,
> >
> > Ingo
> 

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

[Ingo Molnar]

* Ard Biesheuvel <ardb@kernel.org> wrote:

> > 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.

Apparently all GCC < 11.0 versions are crashing.

Would something like the fix below work?

Thanks,

	Ingo

===============>

 lib/zstd/common/portability_macros.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/zstd/common/portability_macros.h b/lib/zstd/common/portability_macros.h
index 0e3b2c0a527d..0dde8bf56595 100644
--- a/lib/zstd/common/portability_macros.h
+++ b/lib/zstd/common/portability_macros.h
@@ -55,7 +55,7 @@
 #ifndef DYNAMIC_BMI2
   #if ((defined(__clang__) && __has_attribute(__target__)) \
       || (defined(__GNUC__) \
-          && (__GNUC__ >= 5 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8)))) \
+          && (__GNUC__ >= 11))) \
       && (defined(__x86_64__) || defined(_M_X64)) \
       && !defined(__BMI2__)
   #  define DYNAMIC_BMI2 1