summaryrefslogtreecommitdiff
path: root/scripts/Makefile.extrawarn
AgeCommit message (Collapse)AuthorFilesLines
2017-04-23kbuild: drop -Wno-unknown-warning-option from clang optionsMasahiro Yamada1-1/+0
Since commit c3f0d0bc5b01 ("kbuild, LLVMLinux: Add -Werror to cc-option to support clang"), cc-option and friends work nicely for clang. However, -Wno-unknown-warning-option makes clang happy with any unknown warning options even if -Werror is specified. Once -Wno-unknown-warning-option is added, any succeeding call of cc-disable-warning is evaluated positive, then unknown warning options are accepted. This should be dropped. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-11-11Kbuild: enable -Wmaybe-uninitialized warnings by defaultArnd Bergmann1-2/+0
Previously the warnings were added back at the W=1 level and above, this now turns them on again by default, assuming that we have addressed all warnings and again have a clean build for v4.10. I found a number of new warnings in linux-next already and submitted bugfixes for those. Hopefully they are caught by the 0day builder in the future as soon as this patch is merged. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-11-11Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"Arnd Bergmann1-0/+3
Traditionally, we have always had warnings about uninitialized variables enabled, as this is part of -Wall, and generally a good idea [1], but it also always produced false positives, mainly because this is a variation of the halting problem and provably impossible to get right in all cases [2]. Various people have identified cases that are particularly bad for false positives, and in commit e74fc973b6e5 ("Turn off -Wmaybe-uninitialized when building with -Os"), I turned off the warning for any build that was done with CC_OPTIMIZE_FOR_SIZE. This drastically reduced the number of false positive warnings in the default build but unfortunately had the side effect of turning the warning off completely in 'allmodconfig' builds, which in turn led to a lot of warnings (both actual bugs, and remaining false positives) to go in unnoticed. With commit 877417e6ffb9 ("Kbuild: change CC_OPTIMIZE_FOR_SIZE definition") enabled the warning again for allmodconfig builds in v4.7 and in v4.8-rc1, I had finally managed to address all warnings I get in an ARM allmodconfig build and most other maybe-uninitialized warnings for ARM randconfig builds. However, commit 6e8d666e9253 ("Disable "maybe-uninitialized" warning globally") was merged at the same time and disabled it completely for all configurations, because of false-positive warnings on x86 that I had not addressed until then. This caused a lot of actual bugs to get merged into mainline, and I sent several dozen patches for these during the v4.9 development cycle. Most of these are actual bugs, some are for correct code that is safe because it is only called under external constraints that make it impossible to run into the case that gcc sees, and in a few cases gcc is just stupid and finds something that can obviously never happen. I have now done a few thousand randconfig builds on x86 and collected all patches that I needed to address every single warning I got (I can provide the combined patch for the other warnings if anyone is interested), so I hope we can get the warning back and let people catch the actual bugs earlier. This reverts the change to disable the warning completely and for now brings it back at the "make W=1" level, so we can get it merged into mainline without introducing false positives. A follow-up patch enables it on all levels unless some configuration option turns it off because of false-positives. Link: https://rusty.ozlabs.org/?p=232 [1] Link: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2] Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-05-11kbuild: move -Wunused-const-variable to W=1 warning levelArnd Bergmann1-0/+1
gcc-6 started warning by default about variables that are not used anywhere and that are marked 'const', generating many false positives in an allmodconfig build, e.g.: arch/arm/mach-davinci/board-da830-evm.c:282:20: warning: 'da830_evm_emif25_pins' defined but not used [-Wunused-const-variable=] arch/arm/plat-omap/dmtimer.c:958:34: warning: 'omap_timer_match' defined but not used [-Wunused-const-variable=] drivers/bluetooth/hci_bcm.c:625:39: warning: 'acpi_bcm_default_gpios' defined but not used [-Wunused-const-variable=] drivers/char/hw_random/omap-rng.c:92:18: warning: 'reg_map_omap4' defined but not used [-Wunused-const-variable=] drivers/devfreq/exynos/exynos5_bus.c:381:32: warning: 'exynos5_busfreq_int_pm' defined but not used [-Wunused-const-variable=] drivers/dma/mv_xor.c:1139:34: warning: 'mv_xor_dt_ids' defined but not used [-Wunused-const-variable=] This is similar to the existing -Wunused-but-set-variable warning that was added in an earlier release and that we disable by default now and only enable when W=1 is set, so it makes sense to do the same here. Once we have eliminated the majority of the warnings for both, we can put them back into the default list. We probably want this in backport kernels as well, to allow building them with gcc-6 without introducing extra warnings. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Olof Johansson <olof@lixom.net> Acked-by: Lee Jones <lee.jones@linaro.org> Cc: stable@vger.kernel.org Signed-off-by: Michal Marek <mmarek@suse.com>
2016-01-12kbuild: Demote 'sign-compare' warning to W=2Lee Jones1-0/+2
Ideally, a kernel compile with W=1 enabled should complete cleanly; however, when we run one currently we are presented with ~25k warnings. 'sign-compare' accounts for ~22k of those ~25k. In this patch we're demoting 'sign-compare' warnings to W=2, with a view to fixing the remaining 3k W=1 warnings required for a clean build. Arnd adds: "As per our discussion, I'd add that this was inadvertedly introduced by Behan when he moved the clang specific warnings into an ifdef block and did not notice that -Wsign-compare was interpreted by both gcc and clang. Earlier, it was introduced in just the same way by Jan-Simon as part of 3d3d6b847420 ("kbuild: LLVMLinux: Adapt warnings for compilation with clang")." Acked-by: Arnd Bergmann <arnd@arndb.de> Fixes: 26ea6bb1fef0 ("kbuild, LLVMLinux: Supress warnings unless W=1-3") Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Michal Marek <mmarek@suse.com>
2015-09-04kbuild: Fix clang detectionMichal Marek1-1/+1
We cannot detect clang before including the arch Makefile, because that can set the default cross compiler. We also cannot detect clang after including the arch Makefile, because powerpc wants to know about clang. Solve this by using an deferred variable. This costs us a few shell invocations, but this is only a constant number. Reported-by: Behan Webster <behanw@converseincode.com> Reported-by: Anton Blanchard <anton@samba.org> Signed-off-by: Michal Marek <mmarek@suse.com>
2014-08-05kbuild, LLVMLinux: Supress warnings unless W=1-3Behan Webster1-10/+11
clang has more warnings enabled by default. Turn them off unless W is set. This patch fixes a logic bug where warnings in clang were disabled when W was set. Signed-off-by: Behan Webster <behanw@converseincode.com> Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de> Signed-off-by: Mark Charlebois <charlebm@gmail.com> Cc: bp@alien8.de Signed-off-by: Michal Marek <mmarek@suse.cz>
2014-04-17kbuild: move extra gcc checks to scripts/Makefile.extrawarnMasahiro Yamada1-0/+67
W=... provides extra gcc checks. Having such code in scripts/Makefile.build results in the same flags being added to KBUILD_CFLAGS multiple times becuase scripts/Makefile.build is invoked every time Kbuild descends into the subdirectories. Since the top Makefile is already too cluttered, this commit moves all of extra gcc check stuff to a new file scripts/Makefile.extrawarn, which is included from the top Makefile. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> CC: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Michal Marek <mmarek@suse.cz>