-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,
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
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
linux-stable-mirror@lists.linaro.org
-
Arnd Bergmann -
Nathan Chancellor