linux-kbuild.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Masahiro Yamada <masahiroy@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Arnd Bergmann <arnd@kernel.org>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Nicolas Schier <nicolas@fjasle.eu>,
	Guenter Roeck <linux@roeck-us.net>, Lee Jones <lee@kernel.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	linux-kbuild@vger.kernel.org,
	Linux-Arch <linux-arch@vger.kernel.org>
Subject: Re: [PATCH 3/9] Kbuild: avoid duplicate warning options
Date: Sun, 20 Aug 2023 10:38:33 +0900	[thread overview]
Message-ID: <CAK7LNARmM9DjHu0gcyVAH1nCf0OVKMq52HvpHtYmCy9E8nKEvQ@mail.gmail.com> (raw)
In-Reply-To: <6574626d-3853-4ef5-a481-5c03894e4ba2@app.fastmail.com>

On Sun, Aug 13, 2023 at 2:45 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Sat, Aug 12, 2023, at 11:21, Masahiro Yamada wrote:
> > On Sat, Aug 12, 2023 at 5:50 PM Arnd Bergmann <arnd@kernel.org> wrote:
> >
> > GCC manual says -Wall implies -Wmaybe-uninitialized.
> >
> > If you move -Wno-maybe-uninitialize to the "W != 2" part,
> > -Wmaybe-uninitialized is unneeded in the 'W == 2" part.
> >
> > Maybe, the same applies to -Wunused-but-set-parameter.
> >
> > Shall we drop warnings implied by another, or
> > is it clearer to explicitly add either -Wfoo or -Wno-foo?
> >
> > If desired, we can do such a clean-up later, though.
>
> Right, we can probably drop that, I've gone back and forth
> on this how to handle these. Some of the warnings are
> handled differently between gcc and clang, or differently
> between compiler versions, where they are sometimes
> implied and sometimes need to be specified explicitly.
>
> What I've tried to do here is to do the change in the least
> invasive way to ensure that this larger patch does not
> change the behavior. My preference would be for you
> to merge it like this unless you see a bug, and then
> do another cleanup pass where we remove the ones implied
> by either -Wall or -Wextra on all known versions.
>
> I'll be on vacation the next few weeks starting on
> Tuesday and will be able to reply to emails, but won't
> have a chance to sufficiently test any significant
> reworks of my series before the merge window.
>
>     Arnd

Applied  to linux-kbuild. Thanks.

-- 
Best Regards
Masahiro Yamada

  reply	other threads:[~2023-08-20  2:53 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-11 14:03 [PATCH 0/9] Kbuild: warning options cleanup and more warnings Arnd Bergmann
2023-08-11 14:03 ` [PATCH 1/9] Kbuild: only pass -fno-inline-functions-called-once for gcc Arnd Bergmann
2023-08-11 14:14   ` Nathan Chancellor
2023-08-11 14:23     ` Arnd Bergmann
2023-08-11 14:03 ` [PATCH 2/9] Kbuild: consolidate warning flags in scripts/Makefile.extrawarn Arnd Bergmann
2023-08-11 14:19   ` Nathan Chancellor
2023-08-11 14:26     ` Arnd Bergmann
2023-08-12  7:21       ` Masahiro Yamada
2023-08-20  1:36       ` Masahiro Yamada
2023-08-11 14:03 ` [PATCH 3/9] Kbuild: avoid duplicate warning options Arnd Bergmann
2023-08-12  9:21   ` Masahiro Yamada
2023-08-12  9:28     ` Arnd Bergmann
2023-08-20  1:38       ` Masahiro Yamada [this message]
2023-08-11 14:03 ` [PATCH 4/9] extrawarn: don't turn off -Wshift-negative-value for gcc-9 Arnd Bergmann
2023-08-12 12:04   ` Masahiro Yamada
2023-08-11 14:03 ` [PATCH 5/9] extrawarn: enable format and stringop overflow warnings in W=1 Arnd Bergmann
2023-08-12 13:10   ` Masahiro Yamada
2023-08-20  1:40     ` Masahiro Yamada
2023-08-21 18:26     ` Nick Desaulniers
2023-08-11 14:03 ` [PATCH 6/9] extrawarn: move -Wrestrict into W=1 warnings Arnd Bergmann
2023-08-12 13:20   ` Masahiro Yamada
2023-08-20  1:45   ` Masahiro Yamada
2023-08-11 14:03 ` [PATCH 7/9] extrawarn: do not disable -Wmain at W=1 level Arnd Bergmann
2023-08-11 14:03 ` [PATCH 8/9] extrawarn: enable more warnings in W=2 Arnd Bergmann
2023-08-11 14:03 ` [PATCH 9/9] [RFC] extrawarn: enable more W=1 warnings by default Arnd Bergmann
2023-08-11 16:09   ` Nathan Chancellor
2023-08-11 18:23     ` Arnd Bergmann
2023-08-14 19:52       ` Nathan Chancellor

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=CAK7LNARmM9DjHu0gcyVAH1nCf0OVKMq52HvpHtYmCy9E8nKEvQ@mail.gmail.com \
    --to=masahiroy@kernel.org \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=lee@kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=nicolas@fjasle.eu \
    --cc=sfr@canb.auug.org.au \
    /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;
as well as URLs for NNTP newsgroup(s).