[PATCH] kbuild: Fully disable -Wenum-{compare-conditional,enum-conversion}

[PATCH] kbuild: Fully disable -Wenum-{compare-conditional,enum-conversion}

[Nathan Chancellor]

-Wenum-enum-conversion and -Wenum-compare-conditional were strengthened
in clang-19 to warn in C mode, which caused the kernel to move them to
W=1 in commit 75b5ab134bb5 ("kbuild: Move
-Wenum-{compare-conditional,enum-conversion} into W=1") because there
were numerous instances of each that would break builds with -Werror.
Unfortunately, this is not a full solution, as more and more developers,
subsystems, and distributors are building with W=1 as well, so they
continue to see the numerous instances of these warnings.

Since the move to W=1, there have not been many new instances that have
appeared through various build reports and the ones that have appeared
seem to be following similar existing patterns, suggesting that most
instances of these warnings will not be real issues. The only
alternatives for silencing these warnings are adding casts (which is
generally seen as an ugly practice) or refactoring the enums to macro
defines or a unified enum (which may be undesirable because of type
safety in other parts of the code).

Disable the warnings altogether so that W=1 users do not see them.

Cc: stable@vger.kernel.org
Fixes: 75b5ab134bb5 ("kbuild: Move -Wenum-{compare-conditional,enum-conversion} into W=1")
Link: https://lore.kernel.org/ZwRA9SOcOjjLJcpi@google.com/
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
I am open to discussion around whether or not to disable this entirely
but I think it needs to be out of W=1.
---
 scripts/Makefile.extrawarn | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
index 1d13cecc7cc7808610e635ddc03476cf92b3a8c1..3f124c80bee5133899047c07bc05e3173ee4c7f0 100644
--- a/scripts/Makefile.extrawarn
+++ b/scripts/Makefile.extrawarn
@@ -31,6 +31,8 @@ KBUILD_CFLAGS-$(CONFIG_CC_NO_ARRAY_BOUNDS) += -Wno-array-bounds
 ifdef CONFIG_CC_IS_CLANG
 # The kernel builds with '-std=gnu11' so use of GNU extensions is acceptable.
 KBUILD_CFLAGS += -Wno-gnu
+KBUILD_CFLAGS += -Wno-enum-compare-conditional
+KBUILD_CFLAGS += -Wno-enum-enum-conversion
 else
 
 # gcc inanely warns about local variables called 'main'
@@ -129,8 +131,6 @@ endif
 KBUILD_CFLAGS += $(call cc-disable-warning, pointer-to-enum-cast)
 KBUILD_CFLAGS += -Wno-tautological-constant-out-of-range-compare
 KBUILD_CFLAGS += $(call cc-disable-warning, unaligned-access)
-KBUILD_CFLAGS += -Wno-enum-compare-conditional
-KBUILD_CFLAGS += -Wno-enum-enum-conversion
 endif
 
 endif

---
base-commit: 8e929cb546ee42c9a61d24fae60605e9e3192354
change-id: 20241016-disable-two-clang-enum-warnings-e7994d44f948

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>

Re: [PATCH] kbuild: Fully disable -Wenum-{compare-conditional,enum-conversion}

[Arnd Bergmann]

On Wed, Oct 16, 2024, at 18:01, Nathan Chancellor wrote:
> -Wenum-enum-conversion and -Wenum-compare-conditional were strengthened
> in clang-19 to warn in C mode, which caused the kernel to move them to
> W=1 in commit 75b5ab134bb5 ("kbuild: Move
> -Wenum-{compare-conditional,enum-conversion} into W=1") because there
> were numerous instances of each that would break builds with -Werror.
> Unfortunately, this is not a full solution, as more and more developers,
> subsystems, and distributors are building with W=1 as well, so they
> continue to see the numerous instances of these warnings.
>
> Since the move to W=1, there have not been many new instances that have
> appeared through various build reports and the ones that have appeared
> seem to be following similar existing patterns, suggesting that most
> instances of these warnings will not be real issues. The only
> alternatives for silencing these warnings are adding casts (which is
> generally seen as an ugly practice) or refactoring the enums to macro
> defines or a unified enum (which may be undesirable because of type
> safety in other parts of the code).
>
> Disable the warnings altogether so that W=1 users do not see them.

I don't think we have to go all the way of completely disabling
the warnings here, they are still potentially useful. I can see
three ways of being less aggressive with them:

- keep -Wno-enum-compare-conditional in W=1 and fix up the
  remaining warnings for that, iirc the Wno-enum-enum-conversion
  is the one that causes the problems.

- Move them to W=2 instead of always disabled

- Leave the warnings enabled for clang-18 and older.

     Arnd

Re: [PATCH] kbuild: Fully disable -Wenum-{compare-conditional,enum-conversion}

[Nathan Chancellor]

On Wed, Oct 16, 2024 at 06:31:27PM +0000, Arnd Bergmann wrote:
> On Wed, Oct 16, 2024, at 18:01, Nathan Chancellor wrote:
> > -Wenum-enum-conversion and -Wenum-compare-conditional were strengthened
> > in clang-19 to warn in C mode, which caused the kernel to move them to
> > W=1 in commit 75b5ab134bb5 ("kbuild: Move
> > -Wenum-{compare-conditional,enum-conversion} into W=1") because there
> > were numerous instances of each that would break builds with -Werror.
> > Unfortunately, this is not a full solution, as more and more developers,
> > subsystems, and distributors are building with W=1 as well, so they
> > continue to see the numerous instances of these warnings.
> >
> > Since the move to W=1, there have not been many new instances that have
> > appeared through various build reports and the ones that have appeared
> > seem to be following similar existing patterns, suggesting that most
> > instances of these warnings will not be real issues. The only
> > alternatives for silencing these warnings are adding casts (which is
> > generally seen as an ugly practice) or refactoring the enums to macro
> > defines or a unified enum (which may be undesirable because of type
> > safety in other parts of the code).
> >
> > Disable the warnings altogether so that W=1 users do not see them.
> 
> I don't think we have to go all the way of completely disabling
> the warnings here, they are still potentially useful. I can see
> three ways of being less aggressive with them:
> 
> - keep -Wno-enum-compare-conditional in W=1 and fix up the
>   remaining warnings for that, iirc the Wno-enum-enum-conversion
>   is the one that causes the problems.
> 
> - Move them to W=2 instead of always disabled
> 
> - Leave the warnings enabled for clang-18 and older.

Arnd and I talked about this offline in the ClangBuiltLinux meeting
today. I am going to run my usual test matrix against a tree with
-Wenum-compare-conditional turned on to see how many instances of these
warnings are in the tree and how difficult it would be to silence them
to address the first point above. I will move -Wenum-enum-conversion to
W=2 and send that as v2 soon to satisfy point two, which should clear up
the blockage for the Android folks.

While disabling the warnings for clang-19 and newer and leaving them on
for clang-18 and older would technically address the issue at hand, it
won't result in increased coverage because the whole point of the change
that caused this in clang-19 is enabling the warning for C code, so
clang-18 and older won't ever emit these warnings.

Cheers,
Nathan