Re: [RFC] clang: 'unused-function' warning on static inline functions

From: Steven Rostedt
Date: Wed Jun 07 2017 - 08:58:11 EST


On Wed, 7 Jun 2017 10:17:18 +0200
Arnd Bergmann <arnd@xxxxxxxx> wrote:

> On Tue, Jun 6, 2017 at 11:29 PM, Jens Axboe <axboe@xxxxxxxxx> wrote:
> > On 06/06/2017 03:23 PM, Matthias Kaehlcke wrote:
> >> El Tue, Jun 06, 2017 at 09:32:35AM -0700 Linus Torvalds ha dit:
> >>
> >>> On Tue, Jun 6, 2017 at 4:16 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> >>>>
> >>>> Those should all be fairly easy to address, I'd vote for leaving the
> >>>> warning enabled
> >>>> in clang, and possibly asking the gcc maintainers to add a similar feature for
> >>>> warning about it.
> >>>
> >>> Hell no. That warning is pointless shit.
> >>
> >> I tend to disagree, the warning is useful to detect truly unused
> >> static inline functions, which should be removed, rather than be
> >> carried around/maintained for often long periods of time.
> >
> > One example is the patch sent for CFQ, which has macros for define
> > functions for setting/clearing bits on the queue:
> >
> > #define CFQ_CFQQ_FNS(name)
> >
> > for one bit, we never clear the bit after we set it, we only set it and
> > later test for it. Hence the clear variant of that function is unused.
> >
> > Now I get a warning. The fix to that would be to define a new variant of
> > CFQ_CFQQ_FNS() that only declares the exact one I need for the version
> > that is never cleared.
> >
> > Or the fix is to just ignore the bogus warning on an unused inline. I
> > greatly prefer the latter.
> >
> > The counter example is this one:
> >
> > http://git.kernel.dk/cgit/linux-block/commit/?id=03ea8ad78cfb2910862c8dfcd2a627fc04097db2
> >
> > where it is truly just dead junk. I'd rather just leave the dead junk
> > than have pointless warnings, if I have to choose one of the two
> > outcomes.
>
> This is a relatively rare case, with an inline function defined by a macro, and
> I sent a patch for a similar one in 1f318a8bafcf ("modules: mark
> __inittest/__exittest
> as __maybe_unused"). I think this is a case where the __maybe_unused
> annotation is reasonable, though for the other instances of unused inline
> functions in .c files, there is often a better way: typically the only caller
> of a function is inside of an #ifdef and moving the inline function definition
> into the same #ifdef block makes it clearer what is going on.
>

How many warnings does the TRACE_EVENT() macros produce? That macro
creates a lot of static inline functions for every event. For example,
it will create an rcuidle() version of a tracepoint for those locations
that need to be called where RCU is not watching. It also adds a
trace_#tracepoint#_enabled() function for those that want to test if
the tracepoint is enabled or not.

That is, every tracepoint creates static inlined functions for cases
that are used by only a few. I'm sure they will cause lots of warnings
because there will be a lot of unused static inlined functions.

-- Steve