mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org, llvm@lists.linux.dev,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, Nick Desaulniers <ndesaulniers@google.com>,
	Bill Wendling <morbo@google.com>,
	Justin Stitt <justinstitt@google.com>,
	Dave Hansen <dave.hansen@intel.com>
Subject: Re: [PATCH v5 1/1] x86/cpu: Make sure flag_is_changeable_p() is always being used
Date: Fri, 08 Nov 2024 18:34:15 +0100	[thread overview]
Message-ID: <106B0D31-F58E-49EA-9FEC-5573B684ACC7@zytor.com> (raw)
In-Reply-To: <20241108172920.GB2564051@thelio-3990X>

On November 8, 2024 6:29:20 PM GMT+01:00, Nathan Chancellor <nathan@kernel.org> wrote:
>On Fri, Nov 08, 2024 at 04:48:16PM +0100, H. Peter Anvin wrote:
>> On November 8, 2024 4:41:16 PM GMT+01:00, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>> >On Fri, Nov 08, 2024 at 04:35:17PM +0100, H. Peter Anvin wrote:
>> >> On November 8, 2024 4:30:10 PM GMT+01:00, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>> >
>> >> >See also commit 6863f5643dd7 ("kbuild: allow Clang to find unused static
>> >> >inline functions for W=1 build").
>> >
>> >^^^ (1)
>> >
>> >> Looks good to me:
>> >> 
>> >> Reviewed-by: H. Peter Anvin (Intel) <hpa@zytor.com>
>> >
>> >Thank you!
>> >
>> >> But another question: why the hell does clang complain about an unused static inline function?!
>> >
>> >Does (1) shed a bit of light to this?
>> >
>> 
>> How on earth is that supposed to work?! We have static inline functions in headers all over the place that are only used in certain circumstances. 
>> 
>> Is this a good thing, really? Or is it noise?
>
>Did you read the commit message of 6863f5643dd7 or just the title?
>
>The difference between Clang and GCC is only around static inline
>function in .c files, not .h files.
>
>  $ cat test.h
>  static inline void unused_inline_in_h(void) {}
>
>  $ cat test.c
>  #include "test.h"
>
>  static inline void unused_inline_in_c(void) {}
>
>  static void unused_in_c(void) {}
>
>  $ gcc -Wall -c -o /dev/null test.c
>  test.c:5:13: warning: ‘unused_in_c’ defined but not used [-Wunused-function]
>      5 | static void unused_in_c(void) {}
>        |             ^~~~~~~~~~~
>
>  $ clang -fsyntax-only -Wall test.c
>  test.c:3:20: warning: unused function 'unused_inline_in_c' [-Wunused-function]
>      3 | static inline void unused_inline_in_c(void) {}
>        |                    ^~~~~~~~~~~~~~~~~~
>  test.c:5:13: warning: unused function 'unused_in_c' [-Wunused-function]
>      5 | static void unused_in_c(void) {}
>        |             ^~~~~~~~~~~
>  2 warnings generated.
>
>I do not think there are too many instances of unused static inline
>functions in .c files but Andy might be able to speak more around how
>many instances he has had to fix across the tree. I can see how this
>difference can be useful for catching dead code and maybe even making
>code cleaner but if it proves to be too much of an annoyance for the
>wider community, we could potentially discuss reverting 6863f5643dd7.
>
>Cheers,
>Nathan

I'm on the road traveling and have limited ability to look things up at the moment. 

However, in .c files the value becomes very very small: in .h files an unused inline becomes a drag on compile time because it effects a number of compilation units, but for a .c file it is just one.

      reply	other threads:[~2024-11-08 17:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-08 15:30 Andy Shevchenko
2024-11-08 15:35 ` H. Peter Anvin
2024-11-08 15:41   ` Andy Shevchenko
2024-11-08 15:48     ` H. Peter Anvin
2024-11-08 16:29       ` Andy Shevchenko
2024-11-08 17:28         ` H. Peter Anvin
2024-11-08 17:29       ` Nathan Chancellor
2024-11-08 17:34         ` H. Peter Anvin [this message]

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=106B0D31-F58E-49EA-9FEC-5573B684ACC7@zytor.com \
    --to=hpa@zytor.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=justinstitt@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=mingo@redhat.com \
    --cc=morbo@google.com \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®