Messages in this thread | | | Date | Wed, 7 Jun 2017 08:58:03 -0400 | From | Steven Rostedt <> | Subject | Re: [RFC] clang: 'unused-function' warning on static inline functions |
| |
On Wed, 7 Jun 2017 10:17:18 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
> On Tue, Jun 6, 2017 at 11:29 PM, Jens Axboe <axboe@kernel.dk> 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@arndb.de> 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
| |