On Mon, Oct 20, 2025 at 05:58:12PM +0200, Matthieu Baerts wrote:
Hi Greg,
On 20/10/2025 15:30, Greg Kroah-Hartman wrote:
On Fri, Oct 17, 2025 at 06:24:01PM +0200, Matthieu Baerts (NGI0) wrote:
Recent fixes have been backported to < v5.18 to fix build issues with GCC 5.15. They all force -std=gnu11 in the CFLAGS, "because [the kernel] requests the gnu11 standard via '-std=' in the main Makefile".
This is true for >= 5.18 versions, but not before. This switch to -std=gnu11 has been done in commit e8c07082a810 ("Kbuild: move to -std=gnu11").
For a question of uniformity, force -std=gnu89, similar to what is done in the main Makefile.
Note: the fixes tags below refers to upstream commits, but this fix is only for kernels not having commit e8c07082a810 ("Kbuild: move to -std=gnu11").
Fixes: 7cbb015e2d3d ("parisc: fix building with gcc-15") Fixes: 3b8b80e99376 ("s390: Add '-std=gnu11' to decompressor and purgatory CFLAGS") Fixes: b3bee1e7c3f2 ("x86/boot: Compile boot code with -std=gnu11 too") Fixes: ee2ab467bddf ("x86/boot: Use '-std=gnu11' to fix build with GCC 15") Fixes: 8ba14d9f490a ("efi: libstub: Use '-std=gnu11' to fix build with GCC 15") Signed-off-by: Matthieu Baerts (NGI0) matttbe@kernel.org
Note: An alternative is to backport commit e8c07082a810 ("Kbuild: move to -std=gnu11"), but I guess we might not want to do that for stable, as it might introduce new warnings.
I would rather do that, as that would allow us to make things align up and be easier to support over the next two years that this kernel needs to be alive for. How much work would that entail?
Good question. I'm not an expert in this area, but I just did a quick test: I backported commit e8c07082a810 ("Kbuild: move to -std=gnu11") and its parent commit 4d94f910e79a ("Kbuild: use -Wdeclaration-after-statement"). A build with 'make allyesconfig' and GCC 5.15 looks OK to me, no warnings.
But when looking a bit around, I noticed these patches have already been suggested to be backported to v5.15 in 2023, but they got removed -- except the doc update, see patch 3/3 -- because they were causing build issues with GCC 8 and 12, see:
https://lore.kernel.org/a2fbbaa2-51d2-4a8c-b032-5331e72cd116@linaro.org
I didn't try to reproduce the issues, but maybe we can re-add them to the v5.15 queue, and ask the CIs to test that?
Note that even if we do that, the first patch will still be needed to have GCC 15 support in v5.15.
Ok, 5.15.y and 5.10.y will be alive for a while, so I'll go queue these up now as odds are, I'll end up hitting this issue myself :)
thanks for the patches!
greg k-h