From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/2] Makefile: Use -fno-strict-aliasing globally
Date: Thu, 20 Sep 2018 09:25:52 -0400 [thread overview]
Message-ID: <20180920132552.GD21228@opus> (raw)
In-Reply-To: <CAEUhbmVTkYOCE96U5e6Eqfi1ZAmkrjLr+XXQpiYV81N3RwQa_g@mail.gmail.com>
On Thu, Sep 20, 2018 at 11:37:36AM +0800, Bin Meng wrote:
> Hi Tom,
>
> On Mon, Sep 17, 2018 at 1:30 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > The -fstrict-aliasing option is implicitly enabled at levels -O2,
> > -O3, -Os by GCC. This option allows the compiler to assume the
> > strictest aliasing rules applicable to the language being compiled.
> > For example, the practice of reading from a different union member
> > than the one most recently written to (called "type-punning") is
> > common. In this case, "type-punning" only works if the memory is
> > accessed through the union type, but might not work by taking the
> > address, casting the resulting pointer and dereferencing the result,
> > which is an undefined behavior per the "strict aliasing rules".
> >
> > GCC's -Wstrict-aliasing (included in -Wall) option does not catch
> > all cases, but does attempt to catch the more common pitfalls. So
> > there are cases that GCC does not report but the codes are violating
> > the "strict aliasing rules".
> >
> > Given lots of codes that may be written to rely on "type-punning",
> > and Linux kernel disables it by -fno-strict-aliasing globally, since
> > U-Boot currently does this on nds32/riscv/x86 builds only, extend
> > this for all architecture builds.
> >
> > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> > Reviewed-by: Tom Rini <trini@konsulko.com>
> > Reviewed-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> > Makefile | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
> When will this series be applied? Another risc-v series has conflicts
> in [PATCH 2/2] and if this is applied in mainline, I can respin my
> risc-v series on top of this to save some time for Rick's handle it
> himself.
I will try and get to this soon, thanks for your patience.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180920/f88b34a0/attachment.sig>
next prev parent reply other threads:[~2018-09-20 13:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-17 5:35 [U-Boot] [PATCH 1/2] Makefile: Use -fno-strict-aliasing globally Bin Meng
2018-09-17 5:35 ` [U-Boot] [PATCH 2/2] config.mk: Remove duplicated -fno-strict-aliasing Bin Meng
2018-09-18 2:05 ` Simon Glass
2018-09-26 12:50 ` [U-Boot] [U-Boot, " Tom Rini
2018-09-20 3:37 ` [U-Boot] [PATCH 1/2] Makefile: Use -fno-strict-aliasing globally Bin Meng
2018-09-20 13:25 ` Tom Rini [this message]
2018-09-26 12:50 ` [U-Boot] [U-Boot, " Tom Rini
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=20180920132552.GD21228@opus \
--to=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/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