[U-Boot] [PATCH 1/2] Makefile: Use -fno-strict-aliasing globally

[U-Boot] [PATCH 1/2] Makefile: Use -fno-strict-aliasing globally

[Bin Meng]

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(-)

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
-- 
2.7.4

[U-Boot] [PATCH 2/2] config.mk: Remove duplicated -fno-strict-aliasing

[Bin Meng]

Now that we already disable the "strict-aliasing" globally, remove
the duplicates in the nds32/riscv/x86 arch-specific Makefiles.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Rick Chen <rick@andestech.com>

---

 arch/nds32/config.mk | 2 +-
 arch/riscv/config.mk | 2 +-
 arch/x86/config.mk   | 1 -
 3 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/nds32/config.mk b/arch/nds32/config.mk
index cb3d8b3..c5520fd 100644
--- a/arch/nds32/config.mk
+++ b/arch/nds32/config.mk
@@ -15,7 +15,7 @@ endif
 CONFIG_STANDALONE_LOAD_ADDR = 0x300000 \
 			      -T $(srctree)/examples/standalone/nds32.lds
 
-PLATFORM_RELFLAGS	+= -fno-strict-aliasing -fno-common -mrelax
+PLATFORM_RELFLAGS	+= -fno-common -mrelax
 PLATFORM_RELFLAGS	+= -gdwarf-2
 PLATFORM_CPPFLAGS	+= -D__nds32__ -G0 -ffixed-10 -fpie
 
diff --git a/arch/riscv/config.mk b/arch/riscv/config.mk
index 219e666..c0b3858 100644
--- a/arch/riscv/config.mk
+++ b/arch/riscv/config.mk
@@ -31,7 +31,7 @@ CONFIG_STANDALONE_LOAD_ADDR = 0x00000000 \
 			      -T $(srctree)/examples/standalone/riscv.lds
 
 PLATFORM_CPPFLAGS	+= -ffixed-gp -fpic
-PLATFORM_RELFLAGS += -fno-strict-aliasing -fno-common -gdwarf-2 -ffunction-sections
+PLATFORM_RELFLAGS += -fno-common -gdwarf-2 -ffunction-sections
 LDFLAGS_u-boot += --gc-sections -static -pie
 
 EFI_CRT0		:= crt0_riscv_efi.o
diff --git a/arch/x86/config.mk b/arch/x86/config.mk
index 5b04feb..cc94071 100644
--- a/arch/x86/config.mk
+++ b/arch/x86/config.mk
@@ -5,7 +5,6 @@
 
 CONFIG_STANDALONE_LOAD_ADDR ?= 0x40000
 
-PLATFORM_CPPFLAGS += -fno-strict-aliasing
 PLATFORM_CPPFLAGS += -fomit-frame-pointer
 PF_CPPFLAGS_X86   := $(call cc-option, -fno-toplevel-reorder, \
 		     $(call cc-option, -fno-unit-at-a-time))
-- 
2.7.4

[U-Boot] [PATCH 2/2] config.mk: Remove duplicated -fno-strict-aliasing

[Simon Glass]

On 16 September 2018 at 23:35, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Now that we already disable the "strict-aliasing" globally, remove
> the duplicates in the nds32/riscv/x86 arch-specific Makefiles.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> Reviewed-by: Rick Chen <rick@andestech.com>
>
> ---
>
>  arch/nds32/config.mk | 2 +-
>  arch/riscv/config.mk | 2 +-
>  arch/x86/config.mk   | 1 -
>  3 files changed, 2 insertions(+), 3 deletions(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH 1/2] Makefile: Use -fno-strict-aliasing globally

[Bin Meng]

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

[U-Boot] [PATCH 1/2] Makefile: Use -fno-strict-aliasing globally

[Tom Rini]

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>

[U-Boot] [U-Boot, 1/2] Makefile: Use -fno-strict-aliasing globally

[Tom Rini]

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!

-- 
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/20180926/ac7c562c/attachment.sig>

[U-Boot] [U-Boot, 2/2] config.mk: Remove duplicated -fno-strict-aliasing

[Tom Rini]

On Sun, Sep 16, 2018 at 10:35:29PM -0700, Bin Meng wrote:

> Now that we already disable the "strict-aliasing" globally, remove
> the duplicates in the nds32/riscv/x86 arch-specific Makefiles.
> 
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> Reviewed-by: Rick Chen <rick@andestech.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>

Applied to u-boot/master, thanks!

-- 
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/20180926/55eba6fb/attachment.sig>