On Fri, 30 Jan 2015, Markos Chandras wrote: > > Agreed, but does it happen for any actual configuration? If so, then the > > configuration is broken and your proposal papers over it, an explicit > > `-march=' option is supposed to be there for all the possible CPU_foo > > settings. At first look it seems to be the case in arch/mips/Makefile, > > but maybe I'm missing something. Besides, a default of `-march=mips32' or > > whatever may not really be adequate for the CPU selected. > > We do have some tools around which default on -march=mips32r6. Then a > loongson3_defconfig build gives this > > kernel/bounds.c:1:0: error: ‘-march=mips32r6’ is not compatible with the > selected ABI > > and that's because in the command line you have no -march=XXXX because > there is none set for CPU_LOONGSON3 > > this is the case I've spotted so far, but if you say that *every* CPU_ > symbol needs to set good cflags then this needs to be addressed in a > different way I suppose. In that case I'd expect `-march=loongson3a' or whatever is appropriate for the architecture to be set. If a fallback is required for older toolchains, then an arrangement similar to one for CPU_SB1 can be made. E.g.: cflags-$(CONFIG_CPU_LOONGSON3) += $(call cc-option,-march=loongson3a,-march=mips64r2) -Wa,--trap or suchlike (based on what GCC says about it). Maciej
