On 4/9/21 9:15 AM, Segher Boessenkool wrote: > On Fri, Apr 09, 2021 at 08:40:42AM +0000, Barbier, Renaud wrote: >> /opt/owc_toolchains/dev/tethys/sysroots/x86_64-owcsdk-linux/usr/libexec/powerpc-oe-linux/gcc/powerpc-oe-linux/10.2.0/as -v -I ./arch/powerpc/include -I ./arch/powerpc/include/generated -I ./include -I ./arch/powerpc/include/uapi -I ./arch/powerpc/include/generated/uapi -I ./include/uapi -I ./include/generated/uapi -I ./arch/powerpc -mppc -many -mbig -me500 -o arch/powerpc/mm/fault.o > > This should work fine. The relevant code in binutils is > > /* If only one bit of the FXM field is set, we can use the new form > of the instruction, which is faster. Unlike the Power4 branch hint > encoding, this is not backward compatible. Do not generate the > new form unless -mpower4 has been given, or -many and the two > operand form of mfcr was used. */ > else if (value > 0 > && (value & -value) == value > && ((dialect & PPC_OPCODE_POWER4) != 0 > || ((dialect & PPC_OPCODE_ANY) != 0 > && (insn & (0x3ff << 1)) == 19 << 1))) > insn |= 1 << 20; > > so I can only conclude that you configured your binutils to default to > Power4 as well? (Or something I don't see is going on.) The "dialect" value is set from the -m<cpu> options, not some default... unless you don't pass in a -m<CPU> option. When I compile a simple mtcrf 2 operand test case using "-mppc -many -mbig -me500", I don't see the mtcrf being translated into a mtocrf, so I guess the question is, can you track down where the mtocrf that is causing the issue is coming from? Meaning, find which obj file it is in and then the source and assembly files that lead to that is. I'd also like to know what the operand(s) are to the mtcrf that is being turned into a mtocrf. Note that this is most likely a kernel source bug or a binutils bug, not a GCC bug. Peter
