summaryrefslogtreecommitdiff
path: root/scripts/Makefile.warn
AgeCommit message (Collapse)Author
2026-09-26kbuild: avoid re-running compiler and linker probesLorenzo Stoakes (ARM)
Each kernel make invocation begins with ~30 compiler and linker runs each of which performs duplicate probe for a number of compiler and linker options. This is useless work - the compiler and its version is known, so use these to determine which options are available, once. Using the newly introduced cc-option-str, track the result of each probe in CC_OPT_*, LD_OPT_* variables and have Makefile's simply append the symbol. Some care has to be taken around negative options, i.e. -Wno-xxx, as gcc accepts an unknown -Wno- without complaint and only complains later, so instead probe the positive form for these cases. Use CC_HAS_* For those probes that gate a Makefile conditional rather than a simple option, as per the established pattern for this. This change avoids a subtle issue with ppc32 (big endian) - clang doesn't accept -fno-stack-clash-protection on this sub-target, so keep this option in the Makefile. With gcc and clang, defconfig and allmodconfig, the recorded command lines are unchanged, a build with nothing to do rebuilds nothing and W=1 continues to function correctly. Doing this improves all builds, but has a particularly positive impact on no-op builds (builds where nothing has changed). Whole build, 128-thread Threadripper 9980X, best of N runs: before after delta ------------------------------- x86 defconfig, no-op make, gcc 0.78s 0.60s -0.18s (-23%) x86 defconfig, no-op make, clang 0.94s 0.66s -0.28s (-30%) x86 defconfig, touch mm/vma.c, gcc 8.6s 8.5s -0.16s (-2%) x86 defconfig, touch mm/vma.c, clang 8.0s 7.7s -0.24s (-3%) x86 defconfig, clean, clang 29.8s 29.4s -0.37s (-1%) x86 allmodconfig, no-op make, gcc 12.9s 12.7s -0.23s (-2%) x86 allmodconfig, no-op make, clang 14.2s 13.9s -0.29s (-2%) x86 allmodconfig, touch mm/vma.c, clang 32.2s 31.9s -0.30s (-1%) Assisted-by: LLM Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Link: https://patch.msgid.link/20260923-build-speedup-v4-12-73128809a4a4@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-05-27scripts/Makefile.warn: Drop -Wformat handling for clang < 16Nathan Chancellor
Now that the minimum supported version of LLVM for building the kernel has been raised to 17.0.1, the block dealing with -Wformat with clang prior to 16 can be removed since the condition for its inclusion is always false. Reviewed-by: Nicolas Schier <nsc@kernel.org> Link: https://patch.msgid.link/20260517-bump-minimum-supported-llvm-version-to-17-v2-10-b3b8cda46bdd@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-03-12kbuild: Consolidate C dialect optionsNathan Chancellor
Introduce CC_FLAGS_DIALECT to make it easier to update the various places in the tree that rely on the GNU C standard and Microsoft extensions flags atomically. All remaining uses of '-std=gnu11' and '-fms-extensions' are in the tools directory (which has its own build system) and other standalone Makefiles. This will allow the kernel to use a narrower option to enable the Microsoft anonymous tagged structure extension in a simpler manner. Place the CC_FLAGS_DIALECT block after the configuration include (so that a future change can move the selection of the flag to Kconfig) but before the arch/$(SRCARCH)/Makefile include (so that CC_FLAGS_DIALECT is available for use in those Makefiles). Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nicolas Schier <nsc@kernel.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Helge Deller <deller@gmx.de> # parisc Link: https://patch.msgid.link/20260223-fms-anonymous-structs-v1-1-8ee406d3c36c@kernel.org Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-01-14kbuild: Drop superfluous compiler option checksThomas Weißschuh
Many of the compiler option checks are not necessary anymore with the current supported versions of compilers (clang 15+, GCC 8.1+). Remove them. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://patch.msgid.link/20260113-kbuild-cc-option-v1-1-011314a0f7f1@weissschuh.net [nathan: Add minor note about currently supported compilers] Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-01-05kbuild: remove gcc's -Wtype-limitsVincent Mailhol
W=2 builds are heavily polluted by the -Wtype-limits warning. Here are some W=12 statistics on Linux v6.19-rc1 for an x86_64 defconfig (with just CONFIG_WERROR set to "n") using gcc 14.3.1: Warning name count percent ------------------------------------------------- -Wlogical-op 2 0.00 % -Wmaybe-uninitialized 138 0.20 % -Wunused-macros 869 1.24 % -Wmissing-field-initializers 1418 2.02 % -Wshadow 2234 3.19 % -Wtype-limits 65378 93.35 % ------------------------------------------------- Total 70039 100.00 % As we can see, -Wtype-limits represents the vast majority of all warnings. The reason behind this is that these warnings appear in some common header files, meaning that some unique warnings are repeated tens of thousands of times (once per header inclusion). Add to this the fact that each warning is coupled with a dozen lines detailing some macro expansion. The end result is that the W=2 output is just too bloated and painful to use. Three years ago, I proposed in [1] modifying one such header to silence that noise. Because the code was not faulty, Linus rejected the idea and instead suggested simply removing that warning. At that time, I could not bring myself to send such a patch because, despite its problems, -Wtype-limits would still catch the below bug: unsigned int ret; ret = check(); if (ret < 0) error(); Meanwhile, based on another suggestion from Linus, I added a new check to sparse [2] that would catch the above bug without the useless spam. With this, remove gcc's -Wtype-limits. People who still want to catch incorrect comparisons between unsigned integers and zero can now use sparse instead. On a side note, clang also has a -Wtype-limits warning but: * it is not enabled in the kernel at the moment because, contrary to gcc, clang did not include it under -Wextra. * it does not warn if the code results from a macro expansion. So, if activated, it would not cause as much spam as gcc does. * -Wtype-limits is split into four sub-warnings [3] meaning that if it were to be activated, we could select which one to keep. So there is no present need to explicitly disable -Wtype-limits in clang. [1] linux/bits.h: GENMASK_INPUT_CHECK: reduce W=2 noise by 31% treewide Link: https://lore.kernel.org/all/20220308141201.2343757-1-mailhol.vincent@wanadoo.fr/ [2] Warn about "unsigned value that used to be signed against zero" Link: https://lore.kernel.org/all/20250921061337.3047616-1-mailhol@kernel.org/ [3] clang's -Wtype-limits Link: https://clang.llvm.org/docs/DiagnosticsReference.html#wtype-limits Reviewed-by: Nicolas Schier <nsc@kernel.org> Signed-off-by: Vincent Mailhol <mailhol@kernel.org> Link: https://patch.msgid.link/20251220-remove_wtype-limits-v3-1-24b170af700e@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2025-11-08kbuild: Rename Makefile.extrawarn to Makefile.warnNathan Chancellor
Since commit e88ca24319e4 ("kbuild: consolidate warning flags in scripts/Makefile.extrawarn"), scripts/Makefile.extrawarn contains all warnings for the main kernel build, not just warnings enabled by the values for W=. Rename it to scripts/Makefile.warn to make it clearer that this Makefile is where all Kbuild warning handling should exist. Signed-off-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20251023-rename-scripts-makefile-extrawarn-v1-1-8f7531542169@kernel.org Signed-off-by: Nicolas Schier <nsc@kernel.org>