[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20241016-disable-two-clang-enum-warnings-v1-1-ae886d7a0269@kernel.org>
Date: Wed, 16 Oct 2024 11:01:43 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Masahiro Yamada <masahiroy@...nel.org>
Cc: Nicolas Schier <nicolas@...sle.eu>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Bill Wendling <morbo@...gle.com>, Justin Stitt <justinstitt@...gle.com>,
Arnd Bergmann <arnd@...db.de>, Aleksei Vetrov <vvvvvv@...gle.com>,
linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org,
llvm@...ts.linux.dev, patches@...ts.linux.dev, stable@...r.kernel.org,
Nathan Chancellor <nathan@...nel.org>
Subject: [PATCH] kbuild: Fully disable
-Wenum-{compare-conditional,enum-conversion}
-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@...r.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@...nel.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@...nel.org>
Powered by blists - more mailing lists