]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
kbuild: remove gcc's -Wtype-limits
authorVincent Mailhol <mailhol@kernel.org>
Sat, 20 Dec 2025 11:02:19 +0000 (12:02 +0100)
committerNathan Chancellor <nathan@kernel.org>
Mon, 5 Jan 2026 23:54:14 +0000 (16:54 -0700)
commit660e899103e29aabcc05447ab20684811ea86107
tree5b34cd9e89c50567c7eacc2d6f7f067de7a42029
parent1b5e068d598e16b3a4ee3fa632108ea393d4e3f1
kbuild: remove gcc's -Wtype-limits

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>
scripts/Makefile.warn