> -----Original Message----- > From: Peter Bergner [mailto:bergner@xxxxxxxxxxxxx] > Sent: 16 April 2021 18:15 > To: Barbier, Renaud <renaud.barbier@xxxxxxxxx> > Cc: gcc-help@xxxxxxxxxxx; Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx> > Subject: Re: gcc 10.2.0 mtocrf instructions on Freescale P1014 (ppc) > > > > [**EXTERNAL SOURCE**]:Please verify the source before clicking link or > opening attachment. > > 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.) > [Barbier, Renaud] I confirm that I donot see power4 being used in the build output > 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. [Barbier, Renaud] So when -mcpu=8540 is enabled the location where the crash happens is in the function fdt_next_node from scripts/dtc/libfdt/fdt.c >From powerpc...objdump of vmlinux: c03037b0: 81 81 00 20 lwz r12,32(r1) c03037b4: 83 a1 00 24 lwz r29,36(r1) c03037b8: 83 c1 00 28 lwz r30,40(r1) c03037bc: 7c 08 03 a6 mtlr r0 c03037c0: 83 e1 00 2c lwz r31,44(r1) c03037c4: 7d 90 81 20 mtocrf 8,r12 <== c03037c8: 38 21 00 30 addi r1,r1,48 c03037cc: 4e 80 00 20 blr I produced the assembly code from the build instructions for fdt.c with the -S option and the instruction is mtcrf: lwz 12,32(1) .cfi_register 70, 12 lwz 29,36(1) .LVL122: .loc 1 273 1 view .LVU476 lwz 30,40(1) .LVL123: .loc 1 273 1 view .LVU477 mtlr 0 .cfi_restore 65 lwz 31,44(1) mtcrf 8,12 <== .cfi_restore 70 addi 1,1,48 > > Note that this is most likely a kernel source bug or a binutils bug, > not a GCC bug. [Barbier, Renaud] My colleague told me that with gcc 9.3.0 with the new binutils, it works. Only the combination gcc 10.2 + new binutils fails. > > Peter
