All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Nathan Chancellor <nathan@kernel.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>,
	Bill Wendling <morbo@google.com>,
	Justin Stitt <justinstitt@google.com>,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Tvrtko Ursulin <tursulin@ursulin.net>,
	David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH v1 0/2] drm/i915/fence: A couple of build fixes
Date: Thu, 29 Aug 2024 21:37:34 +0300	[thread overview]
Message-ID: <87a5gvw4y9.fsf@intel.com> (raw)
In-Reply-To: <20240829182255.GA1468662@thelio-3990X>

On Thu, 29 Aug 2024, Nathan Chancellor <nathan@kernel.org> wrote:
> On Thu, Aug 29, 2024 at 09:10:41PM +0300, Andy Shevchenko wrote:
>> On Thu, Aug 29, 2024 at 07:53:25PM +0300, Andy Shevchenko wrote:
>> > On Thu, Aug 29, 2024 at 07:38:08PM +0300, Jani Nikula wrote:
>> > > On Thu, 29 Aug 2024, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>> > > > With CONFIG_WERROR=y and `make W=1` build fails on my x86_64 machine.
>> > > > This is due to some unused functions. Hence these quick fixes.
>> > > 
>> > > Since when have we been getting the warnings for static inlines?
>
> Since commit 6863f5643dd7 ("kbuild: allow Clang to find unused static
> inline functions for W=1 build"). clang warns about unused static inline
> functions in .c files, unlike GCC (they both do not warn for functions
> coming from .h files). This difference is worked around for the normal
> build by adding '__maybe_unused' to the definition of 'inline' but
> Masahiro wanted to disable it for W=1 to allow this difference to find
> unused/dead code. There have not been too many complaints as far as I am
> aware but I can see how it is surprising.

Heh, I was just going to reply citing the same commit.

I occasionally build with clang myself, and we do enable most W=1 by
default in the drm subsystem, so I was wondering why I hadn't hit
this. The crucial difference is that we lack -DKBUILD_EXTRA_WARN1 which
W=1 adds.

I see there's no subdir-cppflags-y, but I don't see any harm in us
adding -Wundef and -DKBUILD_EXTRA_WARN1 to subdir-ccflags-y. After we
fix the fallout, of course. Do you?

I don't much like the __maybe_unused stuff, but I guess it's fine as a
stopgap measure, and then we can grep for that when running out of
things to do. :p

The TL;DR is,

Reviewed-by: Jani Nikula <jani.nikula@intel.com>

on the series.

BR,
Jani.

-- 
Jani Nikula, Intel

  reply	other threads:[~2024-08-29 18:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-29 15:58 [PATCH v1 0/2] drm/i915/fence: A couple of build fixes Andy Shevchenko
2024-08-29 15:58 ` [PATCH v1 1/2] drm/i915/fence: Mark debug_fence_init_onstack() with __maybe_unused Andy Shevchenko
2024-08-29 15:58 ` [PATCH v1 2/2] drm/i915/fence: Mark debug_fence_free() " Andy Shevchenko
2024-08-29 16:38 ` [PATCH v1 0/2] drm/i915/fence: A couple of build fixes Jani Nikula
2024-08-29 16:53   ` Andy Shevchenko
2024-08-29 18:10     ` Andy Shevchenko
2024-08-29 18:22       ` Nathan Chancellor
2024-08-29 18:37         ` Jani Nikula [this message]
2024-08-29 20:03           ` Nathan Chancellor
2024-09-02  8:27           ` Jani Nikula
2024-09-02 10:20             ` Andy Shevchenko
2024-08-29 17:03 ` ✗ Fi.CI.BUILD: warning for " Patchwork
2024-08-29 17:17 ` ✓ Fi.CI.BAT: success " Patchwork
2024-08-31  0:49 ` ✓ Fi.CI.IGT: " Patchwork

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=87a5gvw4y9.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=airlied@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=justinstitt@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=morbo@google.com \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=tursulin@ursulin.net \
    /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.