toolchain: use -ffp-contract=off on MIPS in the wrapper when needed

This fix is necessary for to build for MIPS, for example for the MIPS XBurst architecture used on ci20 boards.

GCC has replaced (no)mfused-madd with ffp-contract. Find more details and a long discussion at
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00876.html

---
 toolchain/toolchain-wrapper.c  | 10 ++++++++--
 toolchain/toolchain-wrapper.mk |  6 +++++-
 2 files changed, 13 insertions(+), 3 deletions(-)

index 2928ea4..dd3a25e 100644
@@ -79,8 +79,14 @@ static char *predef_args[] = {
 #ifdef BR_OMIT_LOCK_PREFIX
 	"-Wa,-momit-lock-prefix=yes",
 #endif
-#ifdef BR_NO_FUSED_MADD
-	"-mno-fused-madd",
+#ifdef BR2_TOOLCHAIN_GCC_AT_LEAST_4_6
+	#ifdef BR_FP_CONTRACT_OFF
+		"-ffp-contract=off",
+	#endif
+#else
+	#ifdef BR_NO_FUSED_MADD
+		"-mno-fused-madd",
+	#endif
 #endif
 #ifdef BR_BINFMT_FLAT
 	"-Wl,-elf2flt",

index 7f72a0c..b7a4b9b 100644
@@ -28,7 +28,11 @@ endif
 
 # Avoid FPU bug on XBurst CPUs
 ifeq ($(BR2_mips_xburst),y)
-TOOLCHAIN_WRAPPER_ARGS += -DBR_NO_FUSED_MADD
+	ifeq ($(BR2_TOOLCHAIN_GCC_AT_LEAST_4_6),y)
+		TOOLCHAIN_WRAPPER_ARGS += -DBR_FP_CONTRACT_OFF
+	else
+		TOOLCHAIN_WRAPPER_ARGS += -DBR_NO_FUSED_MADD
+	endif
 endif
 
 ifeq ($(BR2_CCACHE_USE_BASEDIR),y)

2.7.4

Hello,

Within just 3 minutes, you sent this patch 3 times. Two times the exact same version, and one time a different version. There is also no version number on the patches, making it very difficult to understand what is *the* correct patch.

Could you add a version number to your patches (git format-patch -v X), include a changelog between version (below the --- sign that follows the Signed-off-by line) and try to avoid sending 3 times the same patch in a row ? :-)

Thanks!

Thomas

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Hello,
I am sorry, I was fully aware that it wasn't a good thing to do. Afterwards. The problem is my lack of experiencie with submissions through git send.
I found some formal mistakes such as missing -s in the submitted patch. Then it was in the middle of a git rebase --interactive and I screwed up. So I fully accept your criticism. Will continue learning and promise to do a more thorough review before sending. Basically I have to get used to the workflow.

Too bad there is no git send --amend

For now please consider the last patch as the correct one.

Regards
Johannes

Am 16.01.2018 21:03 schrieb "Thomas Petazzoni" <
[email protected]>:

Hello,

Within just 3 minutes, you sent this patch 3 times. Two times the exact same version, and one time a different version. There is also no version number on the patches, making it very difficult to understand what is *the* correct patch.

Could you add a version number to your patches (git format-patch -v X), include a changelog between version (below the --- sign that follows the Signed-off-by line) and try to avoid sending 3 times the same patch in a row ? :-)

Thanks!

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180116/5ea947ee/attachment.html>

Thomas,

According to the last mail from Johannes, you should pick his last patch:

<[email protected]>

Which means:

https://patchwork.ozlabs.org/patch/861859/

I can confirm it unbreaks ci20_defconfig:

Thanks,

Ezequiel Garc?a, VanguardiaSur
www.vanguardiasur.com.ar