This fixes a regression caused by commit bb6c0bd3fdb67c8a1fceea1d4700b9ee593309f9 [MIPS: SB1: Fix excessive kernel warnings.], that makes `-march=r5000' selected for compilation flags rather than supposed `-march=sb1' with compilers that do not support the ASE selection flags introduced with that change. For example GCC 4.1.2 supports `-mips3d'/`-mno-mips3d' (and obviously `-march=sb1'), however it does not support `-mdmx'/`-mno-mdmx'. As a result the whole selection of flags fails and compilation resorts to using `-march=r5000', meant for really old compilers indeed only. It is always best to pick the flags individually unless we are absolutely sure a set of flags was introduced to the toolchain together (`-march=sb1' and `-mtune=sb1' would be a good example), and this change makes it happen for CONFIG_CPU_SB1. Consequently the flags ultimately selected with GCC 4.1.2 are `-march=sb1 -Wa,--trap -mno-mips3d' Signed-off-by: Maciej W. Rozycki <macro@xxxxxxxxxxxxxx> --- Ralf, I think we might want to go back to the discussion on using `-march=' vs `-mtune=' -- of course we need to be careful, because occasionally `-march=' does enable instructions useful in the kernel (such as MADD on the NEC Vr5500) beyond ones enabled by the corresponding base architecture (MIPS IV in the case of NEC Vr5500), however in many cases there is indeed no benefit. Richard, this makes me concerned again about backward compatibility of toolchain components. I've been using binutils 2.20.1 for these kernel builds simply because sorting out some unrelated Linux kernel issues took precedence over upgrading old cross-binutils used. However this makes me believe that `-mdmx' and `-mips3d' are now implied in GAS for `-march=sb1' -- has it been always the place? I'm asking because one should in principle be able to upgrade binutils under an old version of the compiler and things are supposed to work unchanged, modulo bug fixes, as long as no new features are used. Overall, perhaps we should try harder here and stick `-Wa,-mno-mdmx' and `-Wa,-mno-mips3d' to be sure as well. I'll see if they are indeed needed when I get to upgrading binutils, and send another patch if so (unless someone else beats me to it, that is, of course). Maciej linux-mips-sb1.patch Index: linux-20140623-swarm64/arch/mips/Makefile =================================================================== --- linux-20140623-swarm64.orig/arch/mips/Makefile +++ linux-20140623-swarm64/arch/mips/Makefile @@ -151,8 +151,10 @@ cflags-$(CONFIG_CPU_NEVADA) += $(call cc -Wa,--trap cflags-$(CONFIG_CPU_RM7000) += $(call cc-option,-march=rm7000,-march=r5000) \ -Wa,--trap -cflags-$(CONFIG_CPU_SB1) += $(call cc-option,-march=sb1 -mno-mdmx -mno-mips3d,-march=r5000) \ +cflags-$(CONFIG_CPU_SB1) += $(call cc-option,-march=sb1,-march=r5000) \ -Wa,--trap +cflags-$(CONFIG_CPU_SB1) += $(call cc-option,-mno-mdmx) +cflags-$(CONFIG_CPU_SB1) += $(call cc-option,-mno-mips3d) cflags-$(CONFIG_CPU_R8000) += -march=r8000 -Wa,--trap cflags-$(CONFIG_CPU_R10000) += $(call cc-option,-march=r10000,-march=r8000) \ -Wa,--trap
