https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65773

            Bug ID: 65773
           Summary: [5.1 regression] GCC 5.1 miscompiles LLVM function
                    AArch64InstrInfo::loadRegFromStackSlot()
           Product: gcc
           Version: 5.1.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: wschmidt at gcc dot gnu.org
                CC: bergner at gcc dot gnu.org, jakub at gcc dot gnu.org,
                    rguenth at gcc dot gnu.org
              Host: powerpc64*-linux-gnu
            Target: powerpc64*-linux-gnu
             Build: powerpc64*-linux-gnu

I built gcc from branches/gcc-5-branch yesterday and used it to build
Clang/LLVM as an acid test.  Unfortunately the test suite shows a number of
failures.  I've traced these down to a miscompile of
AArch64InstrInfo::loadRegFromStackSlot( <long argument list omitted> ).  The
bad code can be seen here:

    105eb74c:   00 00 60 38     li      r3,0
    105eb750:   28 00 41 f9     std     r10,40(r1)
    105eb754:   e4 06 29 79     rldicr  r9,r9,0,59
    105eb758:   30 00 41 f9     std     r10,48(r1)
    105eb75c:   21 00 01 99     stb     r8,33(r1)
    105eb760:   22 00 21 99     stb     r9,34(r1)
    105eb764:   a5 ec 79 48     bl      10d8a408
<_ZN4llvm12MachineInstr10addOp\
erandERNS_15MachineFunctionERKNS_14MachineOperandE+0x8>

This calls MachineInstr::addOperand(MachineFunction&, MachineOperand const&)
with r3 as the this pointer.  Loading zero into the this pointer ahead of the
call seems somewhat unhelpful.

The same code compiled with the 4.8 gcc I usually use shows:

    106a8fa0:   78 cb 25 7f     mr      r5,r25
    106a8fa4:   78 f3 c3 7f     mr      r3,r30
    106a8fa8:   20 00 9e eb     ld      r28,32(r30)
    106a8fac:   78 eb a4 7f     mr      r4,r29
    106a8fb0:   78 d3 46 7f     mr      r6,r26
    106a8fb4:   65 d4 7c 48     bl      10e76418
<_ZNK4llvm12MachineInstr21getR\
egClassConstraintEjPKNS_15TargetInstrInfoEPKNS_18TargetRegisterInfoE+0x8>

which is clearly much more reasonable.

I'll gather reproduction materials, but wanted to get the bug filed quickly for
awareness.

Reply via email to