| Message ID | 1537162529-11113-1-git-send-email-bmeng.cn@gmail.com |
|---|---|
| State | Accepted |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | [U-Boot,1/2] Makefile: Use -fno-strict-aliasing globally | expand |
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. Regards, Bin
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.
On Sun, Sep 16, 2018 at 10:35:28PM -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 <bmeng.cn@gmail.com> > Reviewed-by: Tom Rini <trini@konsulko.com> > Reviewed-by: Simon Glass <sjg@chromium.org> Applied to u-boot/master, thanks!
diff --git a/Makefile b/Makefile index 1891c3a..12f15ba 100644 --- a/Makefile +++ b/Makefile @@ -372,7 +372,7 @@ KBUILD_CPPFLAGS := -D__KERNEL__ -D__UBOOT__ KBUILD_CFLAGS := -Wall -Wstrict-prototypes \ -Wno-format-security \ -fno-builtin -ffreestanding $(CSTD_FLAG) -KBUILD_CFLAGS += -fshort-wchar +KBUILD_CFLAGS += -fshort-wchar -fno-strict-aliasing KBUILD_AFLAGS := -D__ASSEMBLY__ # Don't generate position independent code