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.
prev parent 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®