summaryrefslogtreecommitdiffstats
path: root/scripts/recordmcount.h
diff options
context:
space:
mode:
authorMasahiro Yamada <yamada.masahiro@socionext.com>2019-09-01 01:25:54 +0900
committerMasahiro Yamada <yamada.masahiro@socionext.com>2019-09-06 23:46:52 +0900
commit64a91907c896247c19f8314add2c9baa573fbd3c (patch)
tree66cb5fa5f254b070afaf787cd124cc2f88848d06 /scripts/recordmcount.h
parent60bef52c7a68257048f34ce32b8300def71a3de0 (diff)
downloadlinux-64a91907c896247c19f8314add2c9baa573fbd3c.tar.gz
linux-64a91907c896247c19f8314add2c9baa573fbd3c.tar.bz2
linux-64a91907c896247c19f8314add2c9baa573fbd3c.zip
kbuild: refactor scripts/Makefile.extrawarn
Instead of the warning-[123] magic, let's accumulate compiler options to KBUILD_CFLAGS directly as the top Makefile does. I think this makes it easier to understand what is going on in this file. This commit slightly changes the behavior, I think all of which are OK. [1] Currently, cc-option calls are needlessly evaluated. For example, warning-3 += $(call cc-option, -Wpacked-bitfield-compat) needs evaluating only when W=3, but it is actually evaluated for W=1, W=2 as well. With this commit, only relevant cc-option calls will be evaluated. This is a slight optimization. [2] Currently, unsupported level like W=4 is checked by: $(error W=$(KBUILD_ENABLE_EXTRA_GCC_CHECKS) is unknown) This will no longer be checked, but I do not think it is a big deal. [3] Currently, 4 Clang warnings (Winitializer-overrides, Wformat, Wsign-compare, Wformat-zero-length) are shown by any of W=1, W=2, and W=3. With this commit, they will be warned only by W=1. I think this is a more correct behavior since each warning belongs to only one group. For understanding this commit correctly: We have 3 warning groups, W=1, W=2, and W=3. You may think W=3 has a higher level than W=1, but they are actually independent. If you like, you can combine them like W=13. To enable all the warnings, you can pass W=123. It is shown by 'make help', but not noticed much. Since we support W= combination, there should not exist intersection among the three groups. If we enable Winitializer-overrides for W=1, we do not need to for W=2 or W=3. This is the reason why I think the change [3] makes sense. The documentation says -Winitializer-overrides is enabled by default. (https://clang.llvm.org/docs/DiagnosticsReference.html#winitializer-overrides) We negate it by passing -Wno-initializer-overrides for the normal build, but we do not do that for W=1. This means, W=1 effectively enables -Winitializer-overrides by the clang's default. The same for the other three. Add comments in case people are confused with the code. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Acked-by: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Diffstat (limited to 'scripts/recordmcount.h')
0 files changed, 0 insertions, 0 deletions