Two backports linked to build issues with GCC 15 have failed in this
version:

  - ee2ab467bddf ("x86/boot: Use '-std=gnu11' to fix build with GCC 15")
  - 8ba14d9f490a ("efi: libstub: Use '-std=gnu11' to fix build with GCC 15")

Conflicts have been solved, and described.

After that, this kernel version still didn't build with GCC 15:

  In file included from include/uapi/linux/posix_types.h:5,
                   from include/uapi/linux/types.h:14,
                   from include/linux/types.h:6,
                   from arch/x86/realmode/rm/wakeup.h:11,
                   from arch/x86/realmode/rm/wakemain.c:2:
  include/linux/stddef.h:11:9: error: cannot use keyword 'false' as enumeration constant
     11 |         false   = 0,
        |         ^~~~~
  include/linux/stddef.h:11:9: note: 'false' is a keyword with '-std=c23' onwards
  include/linux/types.h:30:33: error: 'bool' cannot be defined via 'typedef'
     30 | typedef _Bool                   bool;
        |                                 ^~~~
  include/linux/types.h:30:33: note: 'bool' is a keyword with '-std=c23' onwards
  include/linux/types.h:30:1: warning: useless type name in empty declaration
     30 | typedef _Bool                   bool;
        | ^~~~~~~

I initially fixed this by adding -std=gnu11 in arch/x86/Makefile, then I
realised this fix was already done in an upstream commit, created before
the GCC 15 release and not mentioning the error I had. This is patch 3.

When I was investigating my error, I noticed other commits were already
backported to stable versions. They were all adding -std=gnu11 in
different Makefiles. In their commit message, they were mentioning
'gnu11' was picked to use the same as the one from the main Makefile.
But this is not the case in this kernel version. Patch 4 fixes that.

Finally, I noticed extra warnings I didn't have in v5.10. Patch 5 fixes
that.

Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
Alexey Dobriyan (1):
      x86/boot: Compile boot code with -std=gnu11 too

Matthieu Baerts (NGI0) (1):
      arch: back to -std=gnu89 in < v5.18

Nathan Chancellor (3):
      x86/boot: Use '-std=gnu11' to fix build with GCC 15
      efi: libstub: Use '-std=gnu11' to fix build with GCC 15
      kernel/profile.c: use cpumask_available to check for NULL cpumask

 arch/parisc/boot/compressed/Makefile  | 2 +-
 arch/s390/Makefile                    | 2 +-
 arch/s390/purgatory/Makefile          | 2 +-
 arch/x86/Makefile                     | 2 +-
 arch/x86/boot/compressed/Makefile     | 1 +
 drivers/firmware/efi/libstub/Makefile | 2 +-
 kernel/profile.c                      | 6 +++---
 7 files changed, 9 insertions(+), 8 deletions(-)
---
base-commit: cda7d335d88aa30485536aee3027540f41bf4f10
change-id: 20251017-v5-4-gcc-15-2d2ccb30432c

Best regards,
-- 
Matthieu Baerts (NGI0) <matttbe@kernel.org>

On Fri, Oct 17, 2025 at 07:33:37PM +0200, Matthieu Baerts (NGI0) wrote:
> Two backports linked to build issues with GCC 15 have failed in this
> version:
> 
>   - ee2ab467bddf ("x86/boot: Use '-std=gnu11' to fix build with GCC 15")
>   - 8ba14d9f490a ("efi: libstub: Use '-std=gnu11' to fix build with GCC 15")
> 
> Conflicts have been solved, and described.
> 
> After that, this kernel version still didn't build with GCC 15:
> 
>   In file included from include/uapi/linux/posix_types.h:5,
>                    from include/uapi/linux/types.h:14,
>                    from include/linux/types.h:6,
>                    from arch/x86/realmode/rm/wakeup.h:11,
>                    from arch/x86/realmode/rm/wakemain.c:2:
>   include/linux/stddef.h:11:9: error: cannot use keyword 'false' as enumeration constant
>      11 |         false   = 0,
>         |         ^~~~~
>   include/linux/stddef.h:11:9: note: 'false' is a keyword with '-std=c23' onwards
>   include/linux/types.h:30:33: error: 'bool' cannot be defined via 'typedef'
>      30 | typedef _Bool                   bool;
>         |                                 ^~~~
>   include/linux/types.h:30:33: note: 'bool' is a keyword with '-std=c23' onwards
>   include/linux/types.h:30:1: warning: useless type name in empty declaration
>      30 | typedef _Bool                   bool;
>         | ^~~~~~~
> 
> I initially fixed this by adding -std=gnu11 in arch/x86/Makefile, then I
> realised this fix was already done in an upstream commit, created before
> the GCC 15 release and not mentioning the error I had. This is patch 3.
> 
> When I was investigating my error, I noticed other commits were already
> backported to stable versions. They were all adding -std=gnu11 in
> different Makefiles. In their commit message, they were mentioning
> 'gnu11' was picked to use the same as the one from the main Makefile.
> But this is not the case in this kernel version. Patch 4 fixes that.
> 
> Finally, I noticed extra warnings I didn't have in v5.10. Patch 5 fixes
> that.

5.4 is only going to be alive for about 1 more month, so I really don't
think trying to "downgrade" things here is worth it at all.  Anyone
still stuck on this old, obsolete, and very insecure kernel tree isn't
going to be attempting to build it using the bleeding edge gcc release :)

So thanks for the patches, but i'll hold off on them for now.

thanks,

greg k-h

Hi Greg,

Thank you for your reply!

On 20/10/2025 15:29, Greg Kroah-Hartman wrote:
> On Fri, Oct 17, 2025 at 07:33:37PM +0200, Matthieu Baerts (NGI0) wrote:
>> Two backports linked to build issues with GCC 15 have failed in this
>> version:
>>
>>   - ee2ab467bddf ("x86/boot: Use '-std=gnu11' to fix build with GCC 15")
>>   - 8ba14d9f490a ("efi: libstub: Use '-std=gnu11' to fix build with GCC 15")
>>
>> Conflicts have been solved, and described.
>>
>> After that, this kernel version still didn't build with GCC 15:
>>
>>   In file included from include/uapi/linux/posix_types.h:5,
>>                    from include/uapi/linux/types.h:14,
>>                    from include/linux/types.h:6,
>>                    from arch/x86/realmode/rm/wakeup.h:11,
>>                    from arch/x86/realmode/rm/wakemain.c:2:
>>   include/linux/stddef.h:11:9: error: cannot use keyword 'false' as enumeration constant
>>      11 |         false   = 0,
>>         |         ^~~~~
>>   include/linux/stddef.h:11:9: note: 'false' is a keyword with '-std=c23' onwards
>>   include/linux/types.h:30:33: error: 'bool' cannot be defined via 'typedef'
>>      30 | typedef _Bool                   bool;
>>         |                                 ^~~~
>>   include/linux/types.h:30:33: note: 'bool' is a keyword with '-std=c23' onwards
>>   include/linux/types.h:30:1: warning: useless type name in empty declaration
>>      30 | typedef _Bool                   bool;
>>         | ^~~~~~~
>>
>> I initially fixed this by adding -std=gnu11 in arch/x86/Makefile, then I
>> realised this fix was already done in an upstream commit, created before
>> the GCC 15 release and not mentioning the error I had. This is patch 3.
>>
>> When I was investigating my error, I noticed other commits were already
>> backported to stable versions. They were all adding -std=gnu11 in
>> different Makefiles. In their commit message, they were mentioning
>> 'gnu11' was picked to use the same as the one from the main Makefile.
>> But this is not the case in this kernel version. Patch 4 fixes that.
>>
>> Finally, I noticed extra warnings I didn't have in v5.10. Patch 5 fixes
>> that.
> 
> 5.4 is only going to be alive for about 1 more month, so I really don't
> think trying to "downgrade" things here is worth it at all.  Anyone
> still stuck on this old, obsolete, and very insecure kernel tree isn't
> going to be attempting to build it using the bleeding edge gcc release :)

Fine by me for v5.4. I only suggested these very small patches because I
had issues with GCC 15 when building v5.15, and I did the small work for
older kernels.

Please note that the two last patches are not directly linked to GCC 15:

- Patch 4/5 fixes the possible bump to C11 standard for some arch. So if
I'm not mistaken, it changes the minimal requirements from GCC 4.6 to
GCC 4.9. Is it not an issue for such old kernel?
(Note: this patch depends on the parents ones, but can be adapted)

- Patch 5/5 fixes a warning I saw, but I don't know from which version
GCC complains about that.

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.