From: Bruce Richardson <bruce.richardson@intel.com>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>, <dev@dpdk.org>
Subject: Re: [PATCH] build: force gcc to initialize padding bits
Date: Fri, 24 Jan 2025 09:38:20 +0000 [thread overview]
Message-ID: <Z5NfjMe4BRwtPjUm@bricha3-mobl1.ger.corp.intel.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F9E6@smartserver.smartshare.dk>
On Fri, Jan 24, 2025 at 08:48:45AM +0100, Morten Brørup wrote:
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Thursday, 23 January 2025 18.21
> >
> > With GCC 15, the compiler has changed the default behavior when
> > initialization is used for aggregate variables. The new default
> > is to follow the standard (C23) and not initialize everything by
> > default. This breaks assumptions in some drivers and can be
> > lead to other bugs.
> >
> > Use the new zero initialization flag to force the old behavior
> > of initializing everything to zero.
> >
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > ---
> > config/meson.build | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/config/meson.build b/config/meson.build
> > index 6aaad6d8a4..5c8b5a15f5 100644
> > --- a/config/meson.build
> > +++ b/config/meson.build
> > @@ -330,6 +330,9 @@ warning_flags = [
>
> Is warning_flags the right location for this?
> Alternatively, should warning_flags be renamed?
>
+1 to renaming warning flags, to e.g. "global_cflags"?
> > # globally disabled warnings
> > '-Wno-packed-not-aligned',
> > '-Wno-missing-field-initializers',
> > +
> > + # guarantee that everything is zero when using initialization
>
> Maybe add ", like in the C23 standard" to the comment.
>
> > + '-fzero-init-padding-bits=all',
> > ]
> >
> > if not dpdk_conf.get('RTE_ARCH_64')
> > --
> > 2.45.2
>
> I have read up on -fzero-init-padding-bits, and this is the correct solution.
>
Does this flag give us additional guarantees of padding being
zero-initialized that were there before? From my reading of the gcc doc[1],
"..padding-bits=union" corresponds to the old behaviour, right?
This also means we will have different padding behaviour on clang and gcc,
since clang (at least v18 on my board) doesn't support this flag. Do we see
any issues with that?
/Bruce
[1] https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html
> With or without suggested changes:
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
>
next prev parent reply other threads:[~2025-01-24 9:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-23 17:20 Stephen Hemminger
2025-01-24 7:48 ` Morten Brørup
2025-01-24 9:38 ` Bruce Richardson [this message]
2025-01-24 18:37 ` Stephen Hemminger
2025-01-24 18:26 ` [PATCH v2] " Stephen Hemminger
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=Z5NfjMe4BRwtPjUm@bricha3-mobl1.ger.corp.intel.com \
--to=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=mb@smartsharesystems.com \
--cc=stephen@networkplumber.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;
as well as URLs for NNTP newsgroup(s).