From: Nathan Chancellor <natechancellor@gmail.com>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: linux-kbuild@vger.kernel.org,
Nick Desaulniers <ndesaulniers@google.com>,
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
Arnd Bergmann <arnd@arndb.de>, Kees Cook <keescook@chromium.org>,
Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
Michal Marek <michal.lkml@markovi.net>,
Sven Schnelle <svens@stackframe.org>,
Xiaozhou Liu <liuxiaozhou@bytedance.com>,
clang-built-linux@googlegroups.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] kbuild: allow Clang to find unused static inline functions for W=1 build
Date: Wed, 28 Aug 2019 11:20:17 -0700 [thread overview]
Message-ID: <20190828182017.GB127646@archlinux-threadripper> (raw)
In-Reply-To: <20190828055425.24765-2-yamada.masahiro@socionext.com>
On Wed, Aug 28, 2019 at 02:54:25PM +0900, Masahiro Yamada wrote:
> GCC and Clang have different policy for -Wunused-function; GCC does not
> warn unused static inline functions at all whereas Clang does if they
> are defined in source files instead of included headers although it has
> been suppressed since commit abb2ea7dfd82 ("compiler, clang: suppress
> warning for unused static inline functions").
>
> We often miss to delete unused functions where 'static inline' is used
> in *.c files since there is no tool to detect them. Unused code remains
> until somebody notices. For example, commit 075ddd75680f ("regulator:
> core: remove unused rdev_get_supply()").
>
> Let's remove __maybe_unused from the inline macro to allow Clang to
> start finding unused static inline functions. For now, we do this only
> for W=1 build since it is not a good idea to sprinkle warnings for the
> normal build.
>
> My initial attempt was to add -Wno-unused-function for no W=1 build
> (https://lore.kernel.org/patchwork/patch/1120594/)
>
> Nathan Chancellor pointed out that would weaken Clang's checks since
> we would no longer get -Wunused-function without W=1. It is true GCC
> would detect unused static non-inline functions, but it would weaken
> Clang as a standalone compiler at least.
>
> Here is a counter implementation. The current problem is, W=... only
> controls compiler flags, which are globally effective. There is no way
> to narrow the scope to only 'static inline' functions.
>
> This commit defines KBUILD_EXTRA_WARN[123] corresponding to W=[123].
> When KBUILD_EXTRA_WARN1 is defined, __maybe_unused is omitted from
> the 'inline' macro.
>
> This makes the code a bit uglier, so personally I do not want to carry
> this forever. If we can manage to fix most of the warnings, we can
> drop this entirely, then enable -Wunused-function all the time.
>
> If you contribute to code clean-up, please run "make CC=clang W=1"
> and check -Wunused-function warnings. You will find lots of unused
> functions.
>
> Some of them are false-positives because the call-sites are disabled
> by #ifdef. I do not like to abuse the inline keyword for suppressing
> unused-function warnings because it is intended to be a hint for the
> compiler optimization. I prefer #ifdef around the definition, or
> __maybe_unused if #ifdef would make the code too ugly.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
I can still see warnings from static unused functions and with W=1, I
see plenty more. I agree that this is uglier because of the
__inline_maybe_unused but I think this is better for regular developers.
I will try to work on these unused-function warnings!
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
next prev parent reply other threads:[~2019-08-28 18:20 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-28 5:54 [PATCH 1/2] kbuild: refactor scripts/Makefile.extrawarn Masahiro Yamada
2019-08-28 5:54 ` [PATCH 2/2] kbuild: allow Clang to find unused static inline functions for W=1 build Masahiro Yamada
2019-08-28 18:20 ` Nathan Chancellor [this message]
2019-08-28 23:28 ` Nick Desaulniers
2019-08-29 0:05 ` Nathan Chancellor
2019-09-03 15:38 ` Masahiro Yamada
2019-08-30 7:07 ` Sedat Dilek
2019-08-30 9:52 ` Sedat Dilek
2019-09-03 15:39 ` Masahiro Yamada
2019-08-28 7:20 ` [PATCH 1/2] kbuild: refactor scripts/Makefile.extrawarn Sedat Dilek
2019-08-28 14:18 ` Sedat Dilek
2019-08-28 14:21 ` Sedat Dilek
2019-08-28 15:59 ` Sedat Dilek
2019-08-29 17:56 ` Masahiro Yamada
2019-08-28 18:26 ` Nick Desaulniers
2019-08-28 18:17 ` Nathan Chancellor
2019-08-28 22:38 ` Nick Desaulniers
2019-08-29 8:49 ` Sedat Dilek
2019-08-29 9:54 ` Sedat Dilek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190828182017.GB127646@archlinux-threadripper \
--to=natechancellor@gmail.com \
--cc=arnd@arndb.de \
--cc=clang-built-linux@googlegroups.com \
--cc=keescook@chromium.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liuxiaozhou@bytedance.com \
--cc=luc.vanoostenryck@gmail.com \
--cc=michal.lkml@markovi.net \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=ndesaulniers@google.com \
--cc=svens@stackframe.org \
--cc=yamada.masahiro@socionext.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.