On 01/30/2015 04:50 PM, Maciej W. Rozycki wrote: > On Fri, 30 Jan 2015, Markos Chandras wrote: > >>>> cflags-$(CONFIG_SB1XXX_CORELIS) += $(call cc-option,-mno-sched-prolog) \ >>>> -fno-omit-frame-pointer >>>> >>>> ifeq ($(CONFIG_CPU_HAS_MSA),y) >>>> -toolchain-msa := $(call cc-option-yn,-mhard-float -mfp64 >> -Wa$(comma)-mmsa) >>>> +toolchain-msa := $(call cc-option-yn,-march=mips32r2 -mhard-float >> -mfp64 -Wa$(comma)-mmsa) >>>> cflags-$(toolchain-msa) += -DTOOLCHAIN_SUPPORTS_MSA >>>> endif >>> >>> Similarly here, is CPU_HAS_MSA incompatible with `-march=mips64r2'? >> I am not sure but like I explained above, it does not have to be 100% >> accurate. Just something to keep your toolchain happy and really enable >> MSA support even if you happen and old ISA level as the default one for >> your toolchain. >> >> for example, if your toolchain has -march=mips2 as default then >> >> -mhard-float -mfp64 will fail >> >> but >> >> -march=mips32r2 -mhard-float -mfp64 >> >> will pass. Your toolchain does support MSA, but because you combined the >> check with incompatible flags, then the end result is not what you want. > > Hmm doesn't `cc-option-yn' pull options accumulated in $(cflags-y) > already for the check it makes? If not, then it's rather less than useful > for us and I can see two options here: I think it does but IIRC at this point no -march=XXXX was set. Perhaps moving the ASEs checks after the CPU_* code in Makefile to fix this problem indirectly. -- markos
