https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61231
--- Comment #11 from Peter Bergner <bergner at gcc dot gnu.org> --- Looking at some stage2 and stage3 obj files that Matthias sent me, there are actual code differences between the stage2 and stage3 compiles. The following code shows one example. The difference seems to be that the stage2 compile uses an extra non-volatile register to hold one formal argument that will be used as a param for one of the calls, while the stage 3 compile stores it onto the stack and then reloads it just before it's used as a param. Vlad, can you think of any way that your change might affect this? It seems suspicious that your patch forces some pseudos to memory similar to what we are seeing here. Matthias, you said on some systems, you don't see this issue, while on some others (newer?) you do. Can you explain what is different between your good and failing builds? ./stage2-libiberty/pic/xstrdup.o: | ./stage3-libiberty/pic/xstrdup.o: <xstrdup>: <xstrdup>: 0: addis r2,r12,0 0: addis r2,r12,0 4: addi r2,r2,0 4: addi r2,r2,0 8: mflr r0 8: mflr r0 c: std r30,-16(r1) | c: std r31,-8(r1) 10: std r31,-8(r1) | 10: std r0,16(r1) 14: mr r30,r3 | 14: stdu r1,-64(r1) 18: std r0,16(r1) | 18: std r3,32(r1) 1c: stdu r1,-48(r1) | 1c: bl 1c <xstrdup+0x1c> 20: bl 20 <xstrdup+0x20> | 20: nop 24: nop | 24: addi r31,r3,1 28: addi r31,r3,1 | 28: mr r3,r31 2c: mr r3,r31 | 2c: bl 2c <xstrdup+0x2c> 30: bl 30 <xstrdup+0x30> | 30: nop 34: nop | 34: ld r4,32(r1) 38: mr r4,r30 | 38: mr r5,r31 3c: mr r5,r31 | 3c: bl 3c <xstrdup+0x3c> 40: bl 40 <xstrdup+0x40> | 40: nop 44: nop | 44: addi r1,r1,64 48: addi r1,r1,48 | 48: ld r0,16(r1) 4c: ld r0,16(r1) | 4c: ld r31,-8(r1) 50: ld r30,-16(r1) | 50: mtlr r0 54: ld r31,-8(r1) | 54: blr 58: mtlr r0 | 58: .long 0x0 5c: blr | 5c: .long 0x1000000 60: .long 0x0 | 60: .long 0x180 64: .long 0x1000000 < 68: .long 0x280 <
