[Bug target/65773] [5 Regression] GCC 5.1 miscompiles LLVM function AArch64InstrInfo::loadRegFromStackSlot()

2015-04-15 Thread hubicka at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65773

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #4 from Jan Hubicka  ---
Loading NULL as THIS pointer seems fishy indeed. One case I can think of is ICF
merging the method with something else and redirect the call to something else
where parameter 0 has different meaning.

Can you try -fno-icf?

[Bug target/65773] [5 Regression] GCC 5.1 miscompiles LLVM function AArch64InstrInfo::loadRegFromStackSlot()

2015-04-15 Thread wschmidt at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65773

--- Comment #3 from Bill Schmidt  ---
Created attachment 35322
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35322&action=edit
Unreduced save-temps file AArch64InstrInfo.ii.gz

Attaching the (unreduced and compressed) preprocessed source.  So far I haven't
been able to reduce it.  The incorrect code generation can be reproduced with:

$ g++ -O2 -std=c++11 -S AArch64InstrInfo.ii

or with

$ g++ -O1 -std=c++11 -S AArch64InstrInfo.ii

At -O0, there are no calls to
_ZN4llvm12MachineInstr10addOperandERNS_15MachineFunctionERKNS_14MachineOperandE
in the text of the caller, so inlining must be present.  All calls to this
function have reasonable setup code for r3, so -O1 is the minimum optimization
level required to reproduce.

The bad code may be found in the function _ZNK4llvm16AArch64InstrInfo20\
loadRegFromStackSlotERNS_17MachineBasicBlockENS1_15bundle_iteratorINS_12Machine\
InstrENS_14ilist_iteratorIS4_jiPKNS_19TargetRegisterClassEPKNS_18TargetRegi\
sterInfoE, at the third call to
_ZN4llvm12MachineInstr10addOperandERNS_15MachineFunctionERKNS_14MachineOperandE.

[Bug target/65773] [5 Regression] GCC 5.1 miscompiles LLVM function AArch64InstrInfo::loadRegFromStackSlot()

2015-04-15 Thread wschmidt at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65773

--- Comment #2 from Bill Schmidt  ---
Found it...the "real" good code is:

106a8d6c:   78 fb e3 7f mr  r3,r31  
106a8d70:   78 db 64 7f mr  r4,r27  
106a8d74:   20 00 01 99 stb r8,32(r1)   
106a8d78:   00 00 00 39 li  r8,0
106a8d7c:   78 eb a5 7f mr  r5,r29  
106a8d80:   28 00 21 f9 std r9,40(r1)   
106a8d84:   36 00 4a 55 rlwinm  r10,r10,0,0,27  
106a8d88:   30 00 21 f9 std r9,48(r1)   
106a8d8c:   21 00 01 99 stb r8,33(r1)   
106a8d90:   22 00 41 99 stb r10,34(r1)  
106a8d94:   75 ef 7c 48 bl  10e77d08
<_ZN4llvm12MachineInstr10addOp\
erandERNS_15MachineFunctionERKNS_14MachineOperandE+0x8>

[Bug target/65773] [5 Regression] GCC 5.1 miscompiles LLVM function AArch64InstrInfo::loadRegFromStackSlot()

2015-04-15 Thread wschmidt at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65773

--- Comment #1 from Bill Schmidt  ---
Well, I screwed up, the "good" code is calling a different function.  In the
good code this function call was apparently inlined, so I can't point to it. 
But still, the load of r3 with zero is a bad thing.

[Bug target/65773] [5 Regression] GCC 5.1 miscompiles LLVM function AArch64InstrInfo::loadRegFromStackSlot()

2015-04-15 Thread jakub at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65773

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-04-15
Summary|[5.1 regression] GCC 5.1|[5 Regression] GCC 5.1
   |miscompiles LLVM function   |miscompiles LLVM function
   |AArch64InstrInfo::loadRegFr |AArch64InstrInfo::loadRegFr
   |omStackSlot()   |omStackSlot()
 Ever confirmed|0   |1