<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">llvm 1.9 is fairly old. Please move to top of tree and try to reproduce the problem if possible.<div><br class="webkit-block-placeholder"></div><div>Then please file a bugzilla report with reproducible test case and information about system configuration.</div><div><br class="webkit-block-placeholder"></div><div>Thanks,</div><div><br class="webkit-block-placeholder"></div><div>Evan</div><div><br><div><div>On Dec 20, 2007, at 12:54 PM, Ben Mayne wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"> <div> <!-- Converted from text/plain format --><p><font size="2">I sent a long message yesterday describing a problem I thought had to do with the JIT stubs.<br> After further investigating, the problem seems to be in the code generation.<br> <br> The following basic block seems to have an error in it's code generation:<br> <br> __exp.exit: ; preds = %codeRepl258, %__exp_bb_bb.exit<br> phi double [ 1.000000e+00, %codeRepl258 ], [ %.reload.reload.i, %__exp_bb_bb.exit ] ; <double>:30 [#uses=2]<br> %castPointerToLong10 = cast [10 x double]* %DataStore to long ; <long> [#uses=1]<br> %pointerArithmetic11 = add long %castPointerToLong10, 0 ; <long> [#uses=1]<br> %castPointerToLong9 = cast [10 x double]* %DataStore to long ; <long> [#uses=1]<br> %pointerArithmetic10 = add long %castPointerToLong9, 40 ; <long> [#uses=1]<br> %castLongToGV11 = cast long %pointerArithmetic10 to double* ; <double*> [#uses=1]<br> store double 7.000000e+00, double* %castLongToGV11<br> %castPointerToLong12 = cast [10 x double]* %DataStore to long ; <long> [#uses=1]<br> %pointerArithmetic13 = add long %castPointerToLong12, 16 ; <long> [#uses=1]<br> %tmp2.loc = alloca int ; <int*> [#uses=2]<br> %castLongToGV14 = cast long %pointerArithmetic13 to double* ; <double*> [#uses=1]<br> store double 2.000000e+00, double* %castLongToGV14<br> cast int %x to double ; <double>:31 [#uses=1]<br> frem double %31, 1.000000e+02 ; <double>:32 [#uses=2]<br> %castPointerToLong15 = cast [10 x double]* %DataStore to long ; <long> [#uses=1]<br> %pointerArithmetic16 = add long %castPointerToLong15, 24 ; <long> [#uses=1]<br> %castLongToGV17 = cast long %pointerArithmetic16 to double* ; <double*> [#uses=1]<br> store double %32, double* %castLongToGV17<br> %castPointerToLong18 = cast [10 x double]* %DataStore to long ; <long> [#uses=1]<br> %pointerArithmetic19 = add long %castPointerToLong18, 24 ; <long> [#uses=1]<br> %castLongToGV20 = cast long %pointerArithmetic19 to double* ; <double*> [#uses=1]<br> load double* %castLongToGV20 ; <double>:33 [#uses=1]<br> %castPointerToLong21 = cast [10 x double]* %DataStore to long ; <long> [#uses=1]<br> %pointerArithmetic22 = add long %castPointerToLong21, 16 ; <long> [#uses=1]<br> %castLongToGV23 = cast long %pointerArithmetic22 to double* ; <double*> [#uses=1]<br> load double* %castLongToGV23 ; <double>:34 [#uses=1]<br> cast double %34 to int ; <int>:9 [#uses=2]<br> seteq int %9, 0 ; <bool>:7 [#uses=1]<br> br bool %7, label %entry.bb19_crit_edge.i270, label %bb.preheader.i271<br> <br> It gets converted to the following MachineBasicBlock<br> __exp.exit (0x8c58628, LLVM BB @0x8c1c558, ID#21):<br> Predecessors according to CFG: 0x8c53a90 0x8c55b50<br> MOV32mi %EBP, 1, %NOREG, -224, <ga:DataStore><br> %EAX = MOV32rm %EBP, 1, %NOREG, -224<br> %EAX = ADD32ri8 %EAX, 40<br> MOV32mi %EAX, 1, %NOREG, 0, 0<br> MOV32mi %EAX, 1, %NOREG, 4, 1075576832<br> %ESP = SUB32ri %ESP, 16<br> %XMM0 = CVTSI2SDrr %EDI<br> MOVSDmr %ESP, 1, %NOREG, 0, %XMM0<br> MOV32mr %EBP, 1, %NOREG, -268, %ESP<br> ADD32mi8 %EBP, 1, %NOREG, -268, 4294967288<br> %ESP = MOV32rm %EBP, 1, %NOREG, -268<br> %ESI = MOV32rm %EBP, 1, %NOREG, -224<br> %ESI = ADD32ri8 %ESI, 16<br> MOV32mi %ESI, 1, %NOREG, 0, 0<br> MOV32mi %ESI, 1, %NOREG, 4, 1073741824<br> MOV32mi %ESP, 1, %NOREG, 12, 1079574528<br> MOV32mi %ESP, 1, %NOREG, 8, 0<br> CALLpcrel32 <es:fmod><br> %ESP = ADD32ri8 %ESP, 16<br> FSTP64m %EBP, 1, %NOREG, -160<br> %EAX = MOV32rm %EBP, 1, %NOREG, -224<br> %EAX = ADD32ri8 %EAX, 24<br> %XMM0 = MOVSDrm %EBP, 1, %NOREG, -160<br> MOVSDmr %EBP, 1, %NOREG, -232, %XMM0<br> MOVSDmr %EAX, 1, %NOREG, 0, %XMM0<br> %EAX = CVTTSD2SIrm %ESI, 1, %NOREG, 0<br> %ECX = MOV32r0<br> TEST32rr %EAX, %EAX<br> JNE mbb<bb.preheader.i271,0x8c55330><br> Successors according to CFG: 0x8c55330 0x8c573b0<br> <br> The gdb disassembler gives me the following lines for that basic block<br> <br> __exp.exit:<br> 0xf5f6f317: movl $0xa542b70,0xffffff20(%ebp)<br> 0xf5f6f321: mov 0xffffff20(%ebp),%eax<br> 0xf5f6f327: add $0x28,%eax<br> 0xf5f6f32a: movl $0x0,(%eax)<br> 0xf5f6f330: movl $0x401c0000,0x4(%eax)<br> 0xf5f6f337: sub $0x10,%esp<br> 0xf5f6f33d: cvtsi2sd %edi,%xmm0<br> 0xf5f6f341: movsd %xmm0,(%esp)<br> 0xf5f6f346: mov %esp,0xfffffef4(%ebp)<br> 0xf5f6f34c: addl $0xfffffff8,0xfffffef4(%ebp)<br> 0xf5f6f353: mov 0xfffffef4(%ebp),%esp<br> 0xf5f6f359: mov 0xffffff20(%ebp),%esi<br> 0xf5f6f35f: add $0x10,%esi<br> 0xf5f6f362: movl $0x0,(%esi)<br> 0xf5f6f368: movl $0x40000000,0x4(%esi)<br> 0xf5f6f36f: movl $0x40590000,0xc(%esp)<br> 0xf5f6f377: movl $0x0,0x8(%esp)<br> 0xf5f6f37f: call 0xf5f6effb<br> 0xf5f6f384: add $0x10,%esp<br> 0xf5f6f387: fstpl 0xffffff60(%ebp)<br> 0xf5f6f38d: mov 0xffffff20(%ebp),%eax<br> 0xf5f6f393: add $0x18,%eax<br> 0xf5f6f396: movsd 0xffffff60(%ebp),%xmm0<br> 0xf5f6f39e: movsd %xmm0,0xffffff18(%ebp)<br> 0xf5f6f3a6: movsd %xmm0,(%eax)<br> 0xf5f6f3aa: cvttsd2si (%esi),%eax<br> 0xf5f6f3ae: xor %ecx,%ecx<br> 0xf5f6f3b0: test %eax,%eax<br> 0xf5f6f3b2: jne 0xf5f6f3c5<br> <br> <br> The problem I'm seeing is that the generated code for the "%tmp2.loc = alloca int" instruction seems to get placed in the middle of<br> the generated code for the "frem double %31, 1.000000e+02" instruction. The generated code for the frem call subtracts 16 from the stack to<br> prepare for the insertion of arguments onto the stack. However, before it insert the arguments on the stack, it allocates space for tmp2.loc.<br> Therefore the stack essentially gets subtracted by 10 more. Then the arguments are placed on, the call is made, and upon return, 16 is added to<br> the stack. Basically, after the call, the stack doesn't go back to the state it was in before the call because the alloca snuck in between<br> the instructions. Now, tmp2.loc is sitting in memory past the stack pointer which can potentially be overwritten by a future call and in the example<br> I sent yesterday, it does get overwritten.<br> <br> Thanks,<br> <br> Ben Mayne<br> x245<br> <br> </font> </p> </div> _______________________________________________<br>LLVM Developers mailing list<br>LLVMdev@cs.uiuc.edu <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></blockquote></div><br></div></body></html>