public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthias Kaehlcke <mka@chromium.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Doug Anderson <dianders@chromium.org>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Michal Marek <mmarek@suse.com>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Grant Grundler <grundler@chromium.org>,
	Greg Hackmann <ghackmann@google.com>,
	Michael Davidson <md@google.com>
Subject: Re: [PATCH 2/2] kbuild: clang: Disable the 'duplicate-decl-specifier' warning
Date: Wed, 17 May 2017 11:45:29 -0700	[thread overview]
Message-ID: <20170517184529.GG141096@google.com> (raw)
In-Reply-To: <CAK8P3a1y0MoxhMNr2v=R7-CANaATfFy58FM8heyOP78g-JZwHA@mail.gmail.com>

El Wed, May 17, 2017 at 09:35:57AM +0200 Arnd Bergmann ha dit:

> On Tue, May 16, 2017 at 11:41 PM, Doug Anderson <dianders@chromium.org> wrote:
> > Hi
> >
> > On Fri, Apr 21, 2017 at 2:39 PM, Matthias Kaehlcke <mka@chromium.org> wrote:
> >> clang generates plenty of these warnings in different parts of the code.
> >> They are mostly caused by container_of() and other macros which declare
> >> a "const <type> *" variable for their internal use which triggers a
> >> "duplicate 'const' specifier" warning if the <type> is already const
> >> qualified.
> >>
> >> Wording-mostly-from: Michael Davidson <md@google.com>
> >> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> >> ---
> >>  Makefile | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/Makefile b/Makefile
> >> index df5abf346354..6cd6d428db43 100644
> >> --- a/Makefile
> >> +++ b/Makefile
> >> @@ -704,6 +704,7 @@ KBUILD_CFLAGS += $(call cc-disable-warning, unused-variable)
> >>  KBUILD_CFLAGS += $(call cc-disable-warning, format-invalid-specifier)
> >>  KBUILD_CFLAGS += $(call cc-disable-warning, gnu)
> >>  KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member)
> >> +KBUILD_CFLAGS += $(call cc-disable-warning, duplicate-decl-specifier)
> >>  # Quiet clang warning: comparison of unsigned expression < 0 is always false
> >>  KBUILD_CFLAGS += $(call cc-disable-warning, tautological-compare)
> >>  # CLANG uses a _MergedGlobals as optimization, but this breaks modpost, as the
> >
> > It seems like gcc 7 may have the same warning.  Specifically I saw a
> > patch fly by from Arnd, which you can find in Mark Brown's tree now:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/?h=topic/rt5614&id=03ba791df98d15d07ea74075122af71e35c7611c
> >
> >
> > +Arnd since he may be trying to solve the same issues?
> 
> gcc-7 has a warning option with the same name, and I think I have
> fixed all the occurrences we got in mainline (some patches my still
> be in flight). However, it seems that only clang warns about
> 'const typeof(type)' with 'type' being already const.
> 
> I have not looked at clang warnings in a while, how many of these do
> we get overall (aside from container_of)? We might be able
> to turn off this particular warning by sprinkling in
> '_Pragma("clang diagnostic push") _Pragma("clang diagnostic
> ignored \"-Wduplicate-decl-specifier\"")' inside of the macro
> (not sure if clang allows it there, gcc-4.4 and earlier I think did
> not).
> 
> It might also be useful to open a bug against clang so they can
> change it in future releases, as the gcc behavior seems more
> sensible in this instance.

I asked our toolchain folks to follow up with the clang devs. They
asked me for a simple test case, to my suprise clang didn't raise a
warning when building this:

static const int x;
static const typeof(x) y;

It turns out that the warning is only raised when -std=gnu89 (and
potentially others) is set, which is the case of the
kernel. Definitely looks like this should be fixed in clang.

  reply	other threads:[~2017-05-17 18:45 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-21 21:39 [PATCH 0/2] kbuild: clang: Disable spurious warnings Matthias Kaehlcke
2017-04-21 21:39 ` [PATCH 1/2] kbuild: clang: Disable 'address-of-packed-member' warning Matthias Kaehlcke
2017-04-30 13:59   ` Masahiro Yamada
2017-05-02  1:23     ` Matthias Kaehlcke
2017-05-06 16:52       ` Masahiro Yamada
2017-05-08 23:18         ` Matthias Kaehlcke
2017-05-16  6:31           ` Masahiro Yamada
2017-05-16 21:32   ` Doug Anderson
2017-06-22  1:19     ` Masahiro Yamada
2017-04-21 21:39 ` [PATCH 2/2] kbuild: clang: Disable the 'duplicate-decl-specifier' warning Matthias Kaehlcke
2017-04-30 14:01   ` Masahiro Yamada
2017-05-04 19:50     ` Matthias Kaehlcke
2017-05-08  8:29       ` Masahiro Yamada
2017-05-16 21:41   ` Doug Anderson
2017-05-17  7:35     ` Arnd Bergmann
2017-05-17 18:45       ` Matthias Kaehlcke [this message]
2017-05-24  0:04         ` Matthias Kaehlcke
2017-05-24  8:21           ` Arnd Bergmann
2017-06-21  9:11             ` Masahiro Yamada
2017-06-21 10:11               ` Arnd Bergmann
2017-06-21 16:58                 ` Matthias Kaehlcke
2017-06-21 17:59                   ` Arnd Bergmann
2017-06-21 21:19                     ` Matthias Kaehlcke
2017-07-31 16:35                     ` Matthias Kaehlcke

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=20170517184529.GG141096@google.com \
    --to=mka@chromium.org \
    --cc=arnd@arndb.de \
    --cc=dianders@chromium.org \
    --cc=ghackmann@google.com \
    --cc=grundler@chromium.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=md@google.com \
    --cc=mmarek@suse.com \
    --cc=yamada.masahiro@socionext.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox