From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Mon, 10 Sep 2018 17:49:33 -0400 Subject: [U-Boot] [RFC PATCH 1/2] Makefile: Use -fno-strict-aliasing globally In-Reply-To: <1536587626-3664-1-git-send-email-bmeng.cn@gmail.com> References: <1536587626-3664-1-git-send-email-bmeng.cn@gmail.com> Message-ID: <20180910214933.GK4980@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Mon, Sep 10, 2018 at 06:53:45AM -0700, Bin Meng 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 Reviewed-by: Tom Rini -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: