user/sven/linux.git/scripts/Makefile.extrawarn, branch stable/6.0.y

Makefile.extrawarn: Move -Wcast-function-type-strict to W=1

2022-10-12T07:39:04Z

commit 2120635108b35ecad9c59c8b44f6cbdf4f98214e upstream. We enable -Wcast-function-type globally in the kernel to warn about mismatching types in function pointer casts. Compilers currently warn only about ABI incompability with this flag, but Clang 16 will enable a stricter version of the check by default that checks for an exact type match. This will be very noisy in the kernel, so disable -Wcast-function-type-strict without W=1 until the new warnings have been addressed. Cc: stable@vger.kernel.org Link: https://reviews.llvm.org/D134831 Link: https://github.com/ClangBuiltLinux/linux/issues/1724 Suggested-by: Nathan Chancellor Signed-off-by: Sami Tolvanen Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20220930203310.4010564-1-samitolvanen@google.com Signed-off-by: Greg Kroah-Hartman

Makefile.extrawarn: re-enable -Wformat for clang; take 2

2022-09-04T18:15:50Z

-Wformat was recently re-enabled for builds with clang, then quickly re-disabled, due to concerns stemming from the frequency of default argument promotion related warning instances. commit 258fafcd0683 ("Makefile.extrawarn: re-enable -Wformat for clang") commit 21f9c8a13bb2 ("Revert "Makefile.extrawarn: re-enable -Wformat for clang"") ISO WG14 has ratified N2562 to address default argument promotion explicitly for printf, as part of the upcoming ISO C2X standard. The behavior of clang was changed in clang-16 to not warn for the cited cases in all language modes. Add a version check, so that users of clang-16 now get the full effect of -Wformat. For older clang versions, re-enable flags under the -Wformat group that way users still get some useful checks related to format strings, without noisy default argument promotion warnings. I intentionally omitted -Wformat-y2k and -Wformat-security from being re-enabled, which are also part of -Wformat in clang-16. Link: https://github.com/ClangBuiltLinux/linux/issues/378 Link: https://github.com/llvm/llvm-project/issues/57102 Link: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2562.pdf Suggested-by: Justin Stitt Suggested-by: Nathan Chancellor Suggested-by: Youngmin Nam Signed-off-by: Nick Desaulniers Reviewed-by: Masahiro Yamada Reviewed-by: Nathan Chancellor Signed-off-by: Linus Torvalds

scripts/Makefile.extrawarn: Do not disable clang's -Wformat-zero-length

2022-08-20T17:47:48Z

There are no instances of this warning in the tree across several difference architectures and configurations. This was added by commit 26ea6bb1fef0 ("kbuild, LLVMLinux: Supress warnings unless W=1-3") back in 2014, where it might have been necessary, but there are no instances of it now so stop disabling it to increase warning coverage for clang. Signed-off-by: Nathan Chancellor Signed-off-by: Masahiro Yamada

Revert "Makefile.extrawarn: re-enable -Wformat for clang"

2022-08-11T15:40:01Z

This reverts commit 258fafcd0683d9ccfa524129d489948ab3ddc24c. The clang -Wformat warning is terminally broken, and the clang people can't seem to get their act together. This test program causes a warning with clang: #include int main(int argc, char **argv) { printf("%hhu\n", 'a'); } resulting in t.c:5:19: warning: format specifies type 'unsigned char' but the argument has type 'int' [-Wformat] printf("%hhu\n", 'a'); ~~~~ ^~~ %d and apparently clang people consider that a feature, because they don't want to face the reality of how either C character constants, C arithmetic, and C varargs functions work. The rest of the world just shakes their head at that kind of incompetence, and turns off -Wformat for clang again. And no, the "you should use a pointless cast to shut this up" is not a valid answer. That warning should not exist in the first place, or at least be optinal with some "-Wformat-me-harder" kind of option. [ Admittedly, there's also very little reason to *ever* use '%hh[ud]' in C, but what little reason there is is entirely about 'I want to see only the low 8 bits of the argument'. So I would suggest nobody ever use that format in the first place, but if they do, the clang behavious is simply always wrong. Because '%hhu' takes an 'int'. It's that simple. ] Reported-by: Sudip Mukherjee (Codethink) Cc: Nick Desaulniers Signed-off-by: Linus Torvalds

Makefile.extrawarn: re-enable -Wformat for clang

2022-08-03T10:37:59Z

There's been an ongoing mission to re-enable the -Wformat warning for Clang. A previous attempt at enabling the warning showed that there were many instances of this warning throughout the codebase. The sheer amount of these warnings really polluted builds and thus -Wno-format was added to _temporarily_ toggle them off. After many patches the warning has largely been eradicated for x86, x86_64, arm, and arm64 on a variety of configs. The time to enable the warning has never been better as it seems for the first time we are ahead of them and can now solve them as they appear rather than tackling from a backlog. As to the root cause of this large backlog of warnings, Clang seems to pickup on some more nuanced cases of format warnings caused by implicit integer conversion as well as default argument promotions from printf-like functions. Link: https://github.com/ClangBuiltLinux/linux/issues/378 Suggested-by: Nick Desaulniers Signed-off-by: Justin Stitt Signed-off-by: Masahiro Yamada

kbuild: support W=e to make build abort in case of warning

2022-05-07T18:16:59Z

When developing new code/feature, CONFIG_WERROR is most often turned off, especially for people using make W=12 to get more warnings. In such case, turning on -Werror temporarily would require switching on CONFIG_WERROR in the configuration, building, then switching off CONFIG_WERROR. For this use case, this patch introduces a new 'e' modifier to W= as a short hand for KCFLAGS+=-Werror" so that -Werror got added to the kernel (built-in) and modules' CFLAGS. Signed-off-by: Yann Droneaud Signed-off-by: Masahiro Yamada

Kbuild: add -Wno-shift-negative-value where -Wextra is used

2022-03-13T08:30:31Z

As a preparation for moving to -std=gnu11, turn off the -Wshift-negative-value option. This warning is enabled by gcc when building with -Wextra for c99 or higher, but not for c89. Since the kernel already relies on well-defined overflow behavior, the warning is not helpful and can simply be disabled in all locations that use -Wextra. Signed-off-by: Arnd Bergmann Acked-by: Jani Nikula Reviewed-by: Nathan Chancellor Tested-by: Sedat Dilek # LLVM/Clang v13.0.0 (x86-64) Signed-off-by: Masahiro Yamada

Makefile.extrawarn: Move -Wunaligned-access to W=1

2022-02-08T04:20:11Z

-Wunaligned-access is a new warning in clang that is default enabled for arm and arm64 under certain circumstances within the clang frontend (see LLVM commit below). On v5.17-rc2, an ARCH=arm allmodconfig build shows 1284 total/70 unique instances of this warning (most of the instances are in header files), which is quite noisy. To keep a normal build green through CONFIG_WERROR, only show this warning with W=1, which will allow automated build systems to catch new instances of the warning so that the total number can be driven down to zero eventually since catching unaligned accesses at compile time would be generally useful. Cc: stable@vger.kernel.org Link: https://github.com/llvm/llvm-project/commit/35737df4dcd28534bd3090157c224c19b501278a Link: https://github.com/ClangBuiltLinux/linux/issues/1569 Link: https://github.com/ClangBuiltLinux/linux/issues/1576 Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Signed-off-by: Masahiro Yamada

Makefile.extrawarn: remove -Wnested-externs warning

2020-12-08T14:30:05Z

The -Wnested-externs warning has become useless with gcc, since this warns every time that BUILD_BUG_ON() or similar macros are used. With clang, the warning option does nothing to start with, so just remove it entirely. Suggested-by: Nathan Chancellor Signed-off-by: Arnd Bergmann Reviewed-by: Nathan Chancellor Signed-off-by: Masahiro Yamada

Makefile.extrawarn: move -Wcast-align to W=3

2020-11-24T18:36:10Z

This warning behaves differently depending on the architecture and compiler. Using x86 gcc, we get no output at all because gcc knows the architecture can handle unaligned accesses. Using x86 clang, or gcc on an architecture that needs to manually deal with unaligned accesses, the build log is completely flooded with these warnings, as they are commonly invoked by inline functions of networking headers, e.g. include/linux/skbuff.h:1426:26: warning: cast increases required alignment of target type [-Wcast-align] The compiler is correct to point this out, as we are dealing with undefined behavior that does cause problems in practice, but there is also no good way to rewrite the code in commonly included headers to a safer method. Signed-off-by: Arnd Bergmann Reviewed-by: Nathan Chancellor Signed-off-by: Masahiro Yamada