From: David Laight <david.laight.linux@gmail.com>
Some compile time checks significantly bloat the pre-processor output
(particularly when the get nested).
Since the checks aren't really needed on every compilation enable with
W=c (adds -DKBUILD_EXTRA_WARNc) so the checks can be enabled per-build.
Make W=1 imply W=c so the build-bot includes the checks.
As well as reducing the bloat from existing checks (like those in
GENMASK() and FIELD_PREP()) it lets additional checks be added
while there are still 'false positives' without breaking normal builds.
Signed-off-by: David Laight <david.laight.linux@gmail.com>
---
scripts/Makefile.warn | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/scripts/Makefile.warn b/scripts/Makefile.warn
index 68e6fafcb80c..e8a799850973 100644
--- a/scripts/Makefile.warn
+++ b/scripts/Makefile.warn
@@ -2,8 +2,9 @@
# ==========================================================================
# make W=... settings
#
-# There are four warning groups enabled by W=1, W=2, W=3, and W=e
-# They are independent, and can be combined like W=12 or W=123e.
+# There are five warning groups enabled by W=c, W=1, W=2, W=3, and W=e
+# They are independent, and can be combined like W=12 or W=123e,
+# except that W=1 implies W=c.
# ==========================================================================
# Default set of warnings, always enabled
@@ -109,6 +110,13 @@ KBUILD_CFLAGS += $(call cc-option,-Wenum-conversion)
KBUILD_CFLAGS += -Wunused
+#
+# W=c - Expensive compile-time checks, implied by W=1
+#
+ifneq ($(findstring c, $(KBUILD_EXTRA_WARN))$(findstring 1, $(KBUILD_EXTRA_WARN)),)
+KBUILD_CPPFLAGS += -DKBUILD_EXTRA_WARNc
+endif
+
#
# W=1 - warnings which may be relevant and do not occur too often
#
--
2.39.5On Wed, Jan 21, 2026 at 02:57:19PM +0000, david.laight.linux@gmail.com wrote: > From: David Laight <david.laight.linux@gmail.com> > > Some compile time checks significantly bloat the pre-processor output > (particularly when the get nested). > Since the checks aren't really needed on every compilation enable with > W=c (adds -DKBUILD_EXTRA_WARNc) so the checks can be enabled per-build. > Make W=1 imply W=c so the build-bot includes the checks. > > As well as reducing the bloat from existing checks (like those in > GENMASK() and FIELD_PREP()) it lets additional checks be added > while there are still 'false positives' without breaking normal builds. > > Signed-off-by: David Laight <david.laight.linux@gmail.com> Honestly I don't understand this. AFAIU, you've outlined a list of compiler warnings that slow the compilation down, and you group them under 'W=c' option. What is the use case for it outside of your series. I think, a typical user would find more value in an option that enables some warnings but doesn't sacrifices performance. Can you consider flipping the 'W=c' behavior? Can you please explicitly mention warnings included in W=c vs W=1? Can you report compilation time for W=0, W=1 and W=c? What if one needs to enable fast/slow warnings from 2nd or 3rd level? Would W=2c or W=3c work in this case? What does this 'c' stands for? Thanks, Yury > --- > scripts/Makefile.warn | 12 ++++++++++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/scripts/Makefile.warn b/scripts/Makefile.warn > index 68e6fafcb80c..e8a799850973 100644 > --- a/scripts/Makefile.warn > +++ b/scripts/Makefile.warn > @@ -2,8 +2,9 @@ > # ========================================================================== > # make W=... settings > # > -# There are four warning groups enabled by W=1, W=2, W=3, and W=e > -# They are independent, and can be combined like W=12 or W=123e. > +# There are five warning groups enabled by W=c, W=1, W=2, W=3, and W=e > +# They are independent, and can be combined like W=12 or W=123e, > +# except that W=1 implies W=c. > # ========================================================================== > > # Default set of warnings, always enabled > @@ -109,6 +110,13 @@ KBUILD_CFLAGS += $(call cc-option,-Wenum-conversion) > > KBUILD_CFLAGS += -Wunused > > +# > +# W=c - Expensive compile-time checks, implied by W=1 > +# > +ifneq ($(findstring c, $(KBUILD_EXTRA_WARN))$(findstring 1, $(KBUILD_EXTRA_WARN)),) > +KBUILD_CPPFLAGS += -DKBUILD_EXTRA_WARNc > +endif > + > # > # W=1 - warnings which may be relevant and do not occur too often > # > -- > 2.39.5
On Mon, 2 Feb 2026 13:33:22 -0500 Yury Norov <ynorov@nvidia.com> wrote: > On Wed, Jan 21, 2026 at 02:57:19PM +0000, david.laight.linux@gmail.com wrote: > > From: David Laight <david.laight.linux@gmail.com> > > > > Some compile time checks significantly bloat the pre-processor output > > (particularly when the get nested). > > Since the checks aren't really needed on every compilation enable with > > W=c (adds -DKBUILD_EXTRA_WARNc) so the checks can be enabled per-build. > > Make W=1 imply W=c so the build-bot includes the checks. > > > > As well as reducing the bloat from existing checks (like those in > > GENMASK() and FIELD_PREP()) it lets additional checks be added > > while there are still 'false positives' without breaking normal builds. > > > > Signed-off-by: David Laight <david.laight.linux@gmail.com> > > Honestly I don't understand this. AFAIU, you've outlined a list of > compiler warnings that slow the compilation down, and you group them > under 'W=c' option. > > What is the use case for it outside of your series. I think, a typical > user would find more value in an option that enables some warnings but > doesn't sacrifices performance. All the compile-time warnings slow down the compilation. Even apparently trivial ones (like the check in the generic READ_ONCE() that the size is 1, 2, 4 or 8 bytes) have a measurable effect. The code a typical user compiles won't have anything that trips any of the compile-time asserts. They only really happen when compiling new code or adding new checks. > Can you consider flipping the 'W=c' behavior? Why, most of the time you don't want the checks because the code is known to pass them all. It also means it can be used for new checks before all the bugs (and false positives) have been fixed. I did think of just enabling the checks for W=1 builds, but that makes it far to hard to enable them. As it is you can use W=ce to enable them and stop on warnings and errors. Also W=xxx can only really add checks (there are some checks for it being non-empty). Documenting that W=x stopped the 'x' checks being done would be painful. > Can you please explicitly mention warnings included in W=c vs W=1? Can > you report compilation time for W=0, W=1 and W=c? What if one needs to > enable fast/slow warnings from 2nd or 3rd level? Would W=2c or W=3c > work in this case? The W=123 options are all completely independent, my W=c is the same. I'm not sure it is sane to run W=2 rather than W=12, but it is allowed. I made W=1 imply W=1c so that the build bot would pick up the extra checks. Apart from that all the 'W' flags are independent. W=123 fiddle with the command line -W options and set -DKBUILD_EXTRA_WARN[123] so that files can include extra checks. W=c just sets the equivalent -D option. > What does this 'c' stands for? Anything you want it to :-) Discussion session arranged for 2pm-5pm by the bike shed. In some sense it is 'more warnings than default, but not as many as W=1'. Like a lot of the W=1 warnings I wanted to be able to pick up 'code quality' issues without breaking the build for normal people. There are definitely some other checks that could be relegated to W=c once it has been added. I'd also like to add some checks to min_t/max_t/clamp_t to pick up the worst of the dodgy/broken code without having to get all the patches accepted before the test itself is committed. Tests for code like clamp_t(u32, u64_val, 0, ~0u) (yes there are some) tend to get very long and may be problematic if enabled by default (I got burnt by the 10MB expansion of nested min().) David > > Thanks, > Yury > > > --- > > scripts/Makefile.warn | 12 ++++++++++-- > > 1 file changed, 10 insertions(+), 2 deletions(-) > > > > diff --git a/scripts/Makefile.warn b/scripts/Makefile.warn > > index 68e6fafcb80c..e8a799850973 100644 > > --- a/scripts/Makefile.warn > > +++ b/scripts/Makefile.warn > > @@ -2,8 +2,9 @@ > > # ========================================================================== > > # make W=... settings > > # > > -# There are four warning groups enabled by W=1, W=2, W=3, and W=e > > -# They are independent, and can be combined like W=12 or W=123e. > > +# There are five warning groups enabled by W=c, W=1, W=2, W=3, and W=e > > +# They are independent, and can be combined like W=12 or W=123e, > > +# except that W=1 implies W=c. > > # ========================================================================== > > > > # Default set of warnings, always enabled > > @@ -109,6 +110,13 @@ KBUILD_CFLAGS += $(call cc-option,-Wenum-conversion) > > > > KBUILD_CFLAGS += -Wunused > > > > +# > > +# W=c - Expensive compile-time checks, implied by W=1 > > +# > > +ifneq ($(findstring c, $(KBUILD_EXTRA_WARN))$(findstring 1, $(KBUILD_EXTRA_WARN)),) > > +KBUILD_CPPFLAGS += -DKBUILD_EXTRA_WARNc > > +endif > > + > > # > > # W=1 - warnings which may be relevant and do not occur too often > > # > > -- > > 2.39.5
On Mon, Feb 02, 2026 at 08:07:43PM +0000, David Laight wrote: > On Mon, 2 Feb 2026 13:33:22 -0500 > Yury Norov <ynorov@nvidia.com> wrote: > > > On Wed, Jan 21, 2026 at 02:57:19PM +0000, david.laight.linux@gmail.com wrote: > > > From: David Laight <david.laight.linux@gmail.com> > > > > > > Some compile time checks significantly bloat the pre-processor output > > > (particularly when the get nested). > > > Since the checks aren't really needed on every compilation enable with > > > W=c (adds -DKBUILD_EXTRA_WARNc) so the checks can be enabled per-build. > > > Make W=1 imply W=c so the build-bot includes the checks. > > > > > > As well as reducing the bloat from existing checks (like those in > > > GENMASK() and FIELD_PREP()) it lets additional checks be added > > > while there are still 'false positives' without breaking normal builds. > > > > > > Signed-off-by: David Laight <david.laight.linux@gmail.com> > > > > Honestly I don't understand this. AFAIU, you've outlined a list of > > compiler warnings that slow the compilation down, and you group them > > under 'W=c' option. > > > > What is the use case for it outside of your series. I think, a typical > > user would find more value in an option that enables some warnings but > > doesn't sacrifices performance. > > All the compile-time warnings slow down the compilation. > Even apparently trivial ones (like the check in the generic READ_ONCE() > that the size is 1, 2, 4 or 8 bytes) have a measurable effect. > > The code a typical user compiles won't have anything that trips any of > the compile-time asserts. > They only really happen when compiling new code or adding new checks. > > > Can you consider flipping the 'W=c' behavior? > > Why, most of the time you don't want the checks because the code is > known to pass them all. Please don't speculate for what others want. I already said very clearly what I (probably) want - a performance-aware set of warnings. I can tell you for sure what I do not want - a heavyweight subset of W=1 with a partial coverage and similar compile time. > It also means it can be used for new checks before all the bugs (and > false positives) have been fixed. > I did think of just enabling the checks for W=1 builds, but that makes > it far to hard to enable them. > As it is you can use W=ce to enable them and stop on warnings and errors. > > Also W=xxx can only really add checks (there are some checks for it being > non-empty). Documenting that W=x stopped the 'x' checks being done > would be painful. > > > Can you please explicitly mention warnings included in W=c vs W=1? Can > > you report compilation time for W=0, W=1 and W=c? What if one needs to > > enable fast/slow warnings from 2nd or 3rd level? Would W=2c or W=3c > > work in this case? > > The W=123 options are all completely independent, my W=c is the same. > I'm not sure it is sane to run W=2 rather than W=12, but it is allowed. It is allowed and sane. > I made W=1 imply W=1c so that the build bot would pick up the extra checks. > Apart from that all the 'W' flags are independent. > W=123 fiddle with the command line -W options and set -DKBUILD_EXTRA_WARN[123] > so that files can include extra checks. > W=c just sets the equivalent -D option. Again, please: - list all warnings included in W=c and their performance impact; - report build time for W=1 vs W=c vs plain make; - how would your new option work with W=2c, W=3c and so on. > > What does this 'c' stands for? > > Anything you want it to :-) > Discussion session arranged for 2pm-5pm by the bike shed. Meaningless parameter names are not welcome. NAK. > In some sense it is 'more warnings than default, but not as many as W=1'. > Like a lot of the W=1 warnings I wanted to be able to pick up 'code quality' > issues without breaking the build for normal people. > > There are definitely some other checks that could be relegated to W=c > once it has been added. > > I'd also like to add some checks to min_t/max_t/clamp_t to pick up the > worst of the dodgy/broken code without having to get all the patches > accepted before the test itself is committed. > Tests for code like clamp_t(u32, u64_val, 0, ~0u) (yes there are some) > tend to get very long and may be problematic if enabled by default > (I got burnt by the 10MB expansion of nested min().)
On Mon, Feb 02, 2026 at 08:07:43PM +0000, David Laight wrote: > On Mon, 2 Feb 2026 13:33:22 -0500 > Yury Norov <ynorov@nvidia.com> wrote: > > > On Wed, Jan 21, 2026 at 02:57:19PM +0000, david.laight.linux@gmail.com wrote: > > > From: David Laight <david.laight.linux@gmail.com> > > > > > > Some compile time checks significantly bloat the pre-processor output > > > (particularly when the get nested). > > > Since the checks aren't really needed on every compilation enable with > > > W=c (adds -DKBUILD_EXTRA_WARNc) so the checks can be enabled per-build. > > > Make W=1 imply W=c so the build-bot includes the checks. > > > > > > As well as reducing the bloat from existing checks (like those in > > > GENMASK() and FIELD_PREP()) it lets additional checks be added > > > while there are still 'false positives' without breaking normal builds. > > > > > > Signed-off-by: David Laight <david.laight.linux@gmail.com> > > > > Honestly I don't understand this. AFAIU, you've outlined a list of > > compiler warnings that slow the compilation down, and you group them > > under 'W=c' option. > > > > What is the use case for it outside of your series. I think, a typical > > user would find more value in an option that enables some warnings but > > doesn't sacrifices performance. > > All the compile-time warnings slow down the compilation. > Even apparently trivial ones (like the check in the generic READ_ONCE() > that the size is 1, 2, 4 or 8 bytes) have a measurable effect. What kind of difference are we talking about here across a regular build? > The code a typical user compiles won't have anything that trips any of > the compile-time asserts. > They only really happen when compiling new code or adding new checks. > > > Can you consider flipping the 'W=c' behavior? > > Why, most of the time you don't want the checks because the code is > known to pass them all. > > It also means it can be used for new checks before all the bugs (and > false positives) have been fixed. > I did think of just enabling the checks for W=1 builds, but that makes > it far to hard to enable them. > As it is you can use W=ce to enable them and stop on warnings and errors. > > Also W=xxx can only really add checks (there are some checks for it being > non-empty). Documenting that W=x stopped the 'x' checks being done > would be painful. Yeah, I don't think we should be overloading the meaning of W=. > > Can you please explicitly mention warnings included in W=c vs W=1? Can > > you report compilation time for W=0, W=1 and W=c? What if one needs to > > enable fast/slow warnings from 2nd or 3rd level? Would W=2c or W=3c > > work in this case? > > The W=123 options are all completely independent, my W=c is the same. > I'm not sure it is sane to run W=2 rather than W=12, but it is allowed. > > I made W=1 imply W=1c so that the build bot would pick up the extra checks. > Apart from that all the 'W' flags are independent. > W=123 fiddle with the command line -W options and set -DKBUILD_EXTRA_WARN[123] > so that files can include extra checks. > W=c just sets the equivalent -D option. Why even have a different option then? You mention above placing the checks in W=1 makes them too hard to enable but then you say that you made W=1 imply W=c? > > What does this 'c' stands for? > > Anything you want it to :-) > Discussion session arranged for 2pm-5pm by the bike shed. W=c already exists, it is documented as enabling extra Kconfig checks in 'make help'. Maybe W=x for "ex"pensive checks? Or maybe if we really want W=c, maybe rename W=c to W=k for Kconfig? I do not really have a strong preference. > In some sense it is 'more warnings than default, but not as many as W=1'. > Like a lot of the W=1 warnings I wanted to be able to pick up 'code quality' > issues without breaking the build for normal people. So something like a W=0.5? :) > There are definitely some other checks that could be relegated to W=c > once it has been added. > > I'd also like to add some checks to min_t/max_t/clamp_t to pick up the > worst of the dodgy/broken code without having to get all the patches > accepted before the test itself is committed. > Tests for code like clamp_t(u32, u64_val, 0, ~0u) (yes there are some) > tend to get very long and may be problematic if enabled by default > (I got burnt by the 10MB expansion of nested min().) I do not have a super strong opinion about this overall but it feels like this is a bit of a slippery slope with warning fragmentation. I think I would rather see these be treated like regular compiler warnings where the majority of instances are cleaned up then it is added to W=1 to keep the tree clean. Cheers, Nathan
On Mon, 2 Feb 2026 21:47:26 -0700 Nathan Chancellor <nathan@kernel.org> wrote: > On Mon, Feb 02, 2026 at 08:07:43PM +0000, David Laight wrote: > > On Mon, 2 Feb 2026 13:33:22 -0500 > > Yury Norov <ynorov@nvidia.com> wrote: > > > > > On Wed, Jan 21, 2026 at 02:57:19PM +0000, david.laight.linux@gmail.com wrote: > > > > From: David Laight <david.laight.linux@gmail.com> > > > > > > > > Some compile time checks significantly bloat the pre-processor output > > > > (particularly when the get nested). > > > > Since the checks aren't really needed on every compilation enable with > > > > W=c (adds -DKBUILD_EXTRA_WARNc) so the checks can be enabled per-build. > > > > Make W=1 imply W=c so the build-bot includes the checks. > > > > > > > > As well as reducing the bloat from existing checks (like those in > > > > GENMASK() and FIELD_PREP()) it lets additional checks be added > > > > while there are still 'false positives' without breaking normal builds. > > > > > > > > Signed-off-by: David Laight <david.laight.linux@gmail.com> > > > > > > Honestly I don't understand this. AFAIU, you've outlined a list of > > > compiler warnings that slow the compilation down, and you group them > > > under 'W=c' option. > > > > > > What is the use case for it outside of your series. I think, a typical > > > user would find more value in an option that enables some warnings but > > > doesn't sacrifices performance. > > > > All the compile-time warnings slow down the compilation. > > Even apparently trivial ones (like the check in the generic READ_ONCE() > > that the size is 1, 2, 4 or 8 bytes) have a measurable effect. > > What kind of difference are we talking about here across a regular > build? IIRC a couple of %. I repeated a few builds with/without and it was much greater than the variation between the builds. That is a pretty trivial test, but there are a lot of READ_ONCE(). Find a few of those and the difference is significant. > > > The code a typical user compiles won't have anything that trips any of > > the compile-time asserts. > > They only really happen when compiling new code or adding new checks. > > > > > Can you consider flipping the 'W=c' behavior? > > > > Why, most of the time you don't want the checks because the code is > > known to pass them all. > > > > It also means it can be used for new checks before all the bugs (and > > false positives) have been fixed. > > I did think of just enabling the checks for W=1 builds, but that makes > > it far to hard to enable them. > > As it is you can use W=ce to enable them and stop on warnings and errors. > > > > Also W=xxx can only really add checks (there are some checks for it being > > non-empty). Documenting that W=x stopped the 'x' checks being done > > would be painful. > > Yeah, I don't think we should be overloading the meaning of W=. I did thing of supporting W=-e so that you can do W=1-e on a config that enables WERROR, since there isn't much chance of a W=1e build succeeding any time soon. > > > Can you please explicitly mention warnings included in W=c vs W=1? Can > > > you report compilation time for W=0, W=1 and W=c? What if one needs to > > > enable fast/slow warnings from 2nd or 3rd level? Would W=2c or W=3c > > > work in this case? > > > > The W=123 options are all completely independent, my W=c is the same. > > I'm not sure it is sane to run W=2 rather than W=12, but it is allowed. > > > > I made W=1 imply W=1c so that the build bot would pick up the extra checks. > > Apart from that all the 'W' flags are independent. > > W=123 fiddle with the command line -W options and set -DKBUILD_EXTRA_WARN[123] > > so that files can include extra checks. > > W=c just sets the equivalent -D option. > > Why even have a different option then? You mention above placing the > checks in W=1 makes them too hard to enable but then you say that you > made W=1 imply W=c? What I meant was it is hard to see the errors in a W=1 build. So I wanted the enable the checks without picking up W=1. > > > > What does this 'c' stands for? > > > > Anything you want it to :-) > > Discussion session arranged for 2pm-5pm by the bike shed. > > W=c already exists, it is documented as enabling extra Kconfig checks in > 'make help'. Maybe W=x for "ex"pensive checks? Or maybe if we really > want W=c, maybe rename W=c to W=k for Kconfig? I do not really have a > strong preference. It was 'c' for Compile time (a bit silly - but they are source 'compile-time' tests rather then 'run-time' ones). I'd only looked in makefile.warn for other uses. > > In some sense it is 'more warnings than default, but not as many as W=1'. > > Like a lot of the W=1 warnings I wanted to be able to pick up 'code quality' > > issues without breaking the build for normal people. > > So something like a W=0.5? :) That is really what I was looking for. Perhaps setting -DKBUILD_WARN_LEVEL=level*10 would do? So W=1 would set 10, W=2 20 (etc) with some scheme for setting intermediate values (or at least (say) 5). > > There are definitely some other checks that could be relegated to W=c > > once it has been added. > > > > I'd also like to add some checks to min_t/max_t/clamp_t to pick up the > > worst of the dodgy/broken code without having to get all the patches > > accepted before the test itself is committed. > > Tests for code like clamp_t(u32, u64_val, 0, ~0u) (yes there are some) > > tend to get very long and may be problematic if enabled by default > > (I got burnt by the 10MB expansion of nested min().) > > I do not have a super strong opinion about this overall but it feels > like this is a bit of a slippery slope with warning fragmentation. I > think I would rather see these be treated like regular compiler warnings > where the majority of instances are cleaned up then it is added to W=1 > to keep the tree clean. That is slightly different because (mostly) they are warnings from a new compiler version so are picked up by people running the new compiler before they break things and then added to W=1. Adding an extra check to an existing header needs the change committing to get test coverage somewhat earlier - maybe to force some reluctant maintainers to actually fix their code. I definitely needed to conditionally include the checks with W=e but without W=1, this seemed the best way to do it. David > > Cheers, > Nathan
© 2016 - 2026 Red Hat, Inc.