From: Matthias Kaehlcke <mka@chromium.org>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Douglas Anderson <dianders@chromium.org>
Subject: Re: [PATCH 1/3] mm/slub: Only define kmalloc_large_node_hook() for NUMA systems
Date: Tue, 23 May 2017 09:56:08 -0700 [thread overview]
Message-ID: <20170523165608.GN141096@google.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1705221834440.13805@chino.kir.corp.google.com>
Hi David,
El Mon, May 22, 2017 at 06:35:23PM -0700 David Rientjes ha dit:
> On Mon, 22 May 2017, Andrew Morton wrote:
>
> > > > Is clang not inlining kmalloc_large_node_hook() for some reason? I don't
> > > > think this should ever warn on gcc.
> > >
> > > clang warns about unused static inline functions outside of header
> > > files, in difference to gcc.
> >
> > I wish it wouldn't. These patches just add clutter.
> >
>
> Matthias, what breaks if you do this?
>
> diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
> index de179993e039..e1895ce6fa1b 100644
> --- a/include/linux/compiler-clang.h
> +++ b/include/linux/compiler-clang.h
> @@ -15,3 +15,8 @@
> * with any version that can compile the kernel
> */
> #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
> +
> +#ifdef inline
> +#undef inline
> +#define inline __attribute__((unused))
> +#endif
Thanks for the suggestion!
Nothing breaks and the warnings are silenced. It seems we could use
this if there is a stong opposition against having warnings on unused
static inline functions in .c files.
Still I am not convinced that gcc's behavior is preferable in this
case. True, it saves us from adding a bunch of __maybe_unused or
#ifdefs, on the other hand the warning is a useful tool to spot truly
unused code. So far about 50% of the warnings I looked into fall into
this category.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Matthias Kaehlcke <mka@chromium.org>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Douglas Anderson <dianders@chromium.org>
Subject: Re: [PATCH 1/3] mm/slub: Only define kmalloc_large_node_hook() for NUMA systems
Date: Tue, 23 May 2017 09:56:08 -0700 [thread overview]
Message-ID: <20170523165608.GN141096@google.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1705221834440.13805@chino.kir.corp.google.com>
Hi David,
El Mon, May 22, 2017 at 06:35:23PM -0700 David Rientjes ha dit:
> On Mon, 22 May 2017, Andrew Morton wrote:
>
> > > > Is clang not inlining kmalloc_large_node_hook() for some reason? I don't
> > > > think this should ever warn on gcc.
> > >
> > > clang warns about unused static inline functions outside of header
> > > files, in difference to gcc.
> >
> > I wish it wouldn't. These patches just add clutter.
> >
>
> Matthias, what breaks if you do this?
>
> diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
> index de179993e039..e1895ce6fa1b 100644
> --- a/include/linux/compiler-clang.h
> +++ b/include/linux/compiler-clang.h
> @@ -15,3 +15,8 @@
> * with any version that can compile the kernel
> */
> #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
> +
> +#ifdef inline
> +#undef inline
> +#define inline __attribute__((unused))
> +#endif
Thanks for the suggestion!
Nothing breaks and the warnings are silenced. It seems we could use
this if there is a stong opposition against having warnings on unused
static inline functions in .c files.
Still I am not convinced that gcc's behavior is preferable in this
case. True, it saves us from adding a bunch of __maybe_unused or
#ifdefs, on the other hand the warning is a useful tool to spot truly
unused code. So far about 50% of the warnings I looked into fall into
this category.
next prev parent reply other threads:[~2017-05-23 16:56 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-19 21:00 [PATCH 0/3] mm/slub: Fix unused function warnings Matthias Kaehlcke
2017-05-19 21:00 ` Matthias Kaehlcke
2017-05-19 21:00 ` [PATCH 1/3] mm/slub: Only define kmalloc_large_node_hook() for NUMA systems Matthias Kaehlcke
2017-05-19 21:00 ` Matthias Kaehlcke
2017-05-22 20:39 ` David Rientjes
2017-05-22 20:39 ` David Rientjes
2017-05-22 20:56 ` Matthias Kaehlcke
2017-05-22 20:56 ` Matthias Kaehlcke
2017-05-22 21:45 ` Andrew Morton
2017-05-22 21:45 ` Andrew Morton
2017-05-23 1:35 ` David Rientjes
2017-05-23 1:35 ` David Rientjes
2017-05-23 16:56 ` Matthias Kaehlcke [this message]
2017-05-23 16:56 ` Matthias Kaehlcke
2017-05-23 17:12 ` Doug Anderson
2017-05-23 17:12 ` Doug Anderson
2017-05-24 20:36 ` David Rientjes
2017-05-24 20:36 ` David Rientjes
2017-05-24 22:09 ` Matthias Kaehlcke
2017-05-24 22:09 ` Matthias Kaehlcke
2017-05-26 17:05 ` Doug Anderson
2017-05-26 17:05 ` Doug Anderson
2017-05-19 21:00 ` [PATCH 2/3] mm/slub: Mark slab_free_hook() as __maybe_unused Matthias Kaehlcke
2017-05-19 21:00 ` Matthias Kaehlcke
2017-05-19 21:00 ` [PATCH 3/3] mm/slub: Put tid_to_cpu() and tid_to_event() inside #ifdef block Matthias Kaehlcke
2017-05-19 21:00 ` Matthias Kaehlcke
2017-05-22 15:24 ` [PATCH 0/3] mm/slub: Fix unused function warnings Christoph Lameter
2017-05-22 15:24 ` Christoph Lameter
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=20170523165608.GN141096@google.com \
--to=mka@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=dianders@chromium.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.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.