All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Marek Behún" <kabel@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Nathan Chancellor <natechancellor@gmail.com>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Andrew Lunn <andrew@lunn.ch>, Networking <netdev@vger.kernel.org>
Subject: Re: [PATCH kbuild] Makefile.extrawarn: disable -Woverride-init in W=1
Date: Wed, 7 Apr 2021 22:44:06 +0200	[thread overview]
Message-ID: <20210407224406.5420258b@thinkpad> (raw)
In-Reply-To: <CAK8P3a0_ruZSMv-kLMY7Jja7wq0K3aNNDviYqQPmN-3UayiHaQ@mail.gmail.com>

On Wed, 7 Apr 2021 09:14:29 +0200
Arnd Bergmann <arnd@arndb.de> wrote:

> On Wed, Apr 7, 2021 at 2:24 AM Marek Behún <kabel@kernel.org> wrote:
> >
> > The -Wextra flag enables -Woverride-init in newer versions of GCC.
> >
> > This causes the compiler to warn when a value is written twice in a
> > designated initializer, for example:
> >   int x[1] = {
> >     [0] = 3,
> >     [0] = 3,
> >   };
> >
> > Note that for clang, this was disabled from the beginning with
> > -Wno-initializer-overrides in commit a1494304346a3 ("kbuild: add all
> > Clang-specific flags unconditionally").
> >
> > This prevents us from implementing complex macros for compile-time
> > initializers.  
> 
> I think this is generally a useful warning, and it has found a number
> of real bugs. I would want this to be enabled in both gcc and clang
> by default, and I have previously sent both bugfixes and patches to
> disable it locally.
> 
> > For example a macro of the form INITIALIZE_BITMAP(bits...) that can be
> > used as
> >   static DECLARE_BITMAP(bm, 64) = INITIALIZE_BITMAP(0, 1, 32, 33);
> > can only be implemented by allowing a designated initializer to
> > initialize the same members multiple times (because the compiler
> > complains even if the multiple initializations initialize to the same
> > value).  
> 
> We don't have this kind of macro at the moment, and this may just mean
> you need to try harder to come up with a definition that only initializes
> each member once if you want to add this.
> 
> How do you currently define it?
> 
>             Arnd

Arnd,

since it is possible to create a macro which will expand N times if N
is a preprocessor numeric constant, i.e.
  EXPAND_N_TIMES(3, macro, args...)
would expand to
  macro(1, args...) macro(2, args...) macro(3, args...)

But the first argument to this EXPAND_N_TIMES macro would have to be a
number when preprocessing, so no expression via division, nor enums.

Example:

  The PHY_INTERFACE_MODE_* constants are defined via enum, and
  the last is PHY_INTERFACE_MODE_MAX.

  We could then implement bitmap initializers for PHY_INTERFACE_MODE
  bitmap in the following way:

  enum {
    ...
    PHY_INTERFACE_MODE_MAX
  };

  /* assume PHY_INTERFACE_MODE_MASK has value 50, so 2 longs on 32-bit
   * and 1 long on 64-bit. These have to be direct constant, no expressions
   * allowed. If more PHY_INTERFACE_MODE_* constants are added to the enum
   * above, the following must be changed accordingly. The static_assert
   * below guards against invalid value.
   */

  #define PHY_INTERFACE_BITMAP_LONGS_64  1
  #define PHY_INTERFACE_BITMAP_LONGS_32  2

  /* check if PHY_INTERFACE_BITMAP_LONGS_* have correct values */
  static_assert(PHY_INTERFACE_BITMAP_LONGS_64 ==
                DIV_ROUND_UP(PHY_INTERFACE_MODE_MASK, 64));
  static_assert(PHY_INTERFACE_BITMAP_LONGS_32 ==
                DIV_ROUND_UP(PHY_INTERFACE_MODE_MASK, 32));

  #define DECLARE_PHY_INTERFACE_MASK(name) \
    DECLARE_BITMAP(name, PHY_INTERFACE_MODE_MAX)

  #define INIT_PHY_INTERFACE_MASK(...) \
    INITIALIZE_BITMAP(PHY_INTERFACE_BITMAP_LONGS, ##__VA_ARGS__)

What do you think?

Marek

      parent reply	other threads:[~2021-04-07 20:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-07  0:24 [PATCH kbuild] Makefile.extrawarn: disable -Woverride-init in W=1 Marek Behún
2021-04-07  7:14 ` Arnd Bergmann
2021-04-07 14:49   ` Marek Behún
2021-04-07 20:44   ` Marek Behún [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=20210407224406.5420258b@thinkpad \
    --to=kabel@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=arnd@arndb.de \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=natechancellor@gmail.com \
    --cc=netdev@vger.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 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.