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.