From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751536AbdFGM6J (ORCPT ); Wed, 7 Jun 2017 08:58:09 -0400 Received: from mail.kernel.org ([198.145.29.99]:60266 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751203AbdFGM6I (ORCPT ); Wed, 7 Jun 2017 08:58:08 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BC35623954 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Wed, 7 Jun 2017 08:58:03 -0400 From: Steven Rostedt To: Arnd Bergmann Cc: Jens Axboe , Matthias Kaehlcke , Linus Torvalds , Linux Kernel Mailing List , Andrew Morton , Greg Kroah-Hartman , Ingo Molnar , Thomas Gleixner , Christoph Hellwig , David Rientjes , Douglas Anderson , Guenter Roeck , Mark Brown , David Miller Subject: Re: [RFC] clang: 'unused-function' warning on static inline functions Message-ID: <20170607085803.04829eb5@gandalf.local.home> In-Reply-To: References: <20170530181306.GV141096@google.com> <20170531235519.GX141096@google.com> <20170606212354.GZ141096@google.com> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 7 Jun 2017 10:17:18 +0200 Arnd Bergmann wrote: > On Tue, Jun 6, 2017 at 11:29 PM, Jens Axboe 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 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