<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">HI Jiangning,<div><br></div><div>thanks for following up on this. I’m all up for using clang/llvm as the build compiler on all bots. :-) Compile time should be much faster, too.</div><div><br></div><div>It seems the next steps are:</div><div><br></div><div>1) I’ll work around in the code in the short term, since I expect changing the build compiler on all bots will take a while, right?</div><div>2) I’ll file a bug against gcc so someone has a chance to fix it. Test cases for these kind of fails are often hard to come by.</div><div><br></div><div>Cheers</div><div>Gerolf</div><div><br></div><div><br><div><div>On Aug 6, 2014, at 12:35 AM, Jiangning Liu <<a href="mailto:liujiangning1@gmail.com">liujiangning1@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Hi Gerolf,<div><br></div><div class="gmail_extra"><br><div class="gmail_quote">2014-08-06 12:19 GMT+08:00 Gerolf Hoflehner <span dir="ltr"><<a href="mailto:ghoflehner@apple.com" target="_blank">ghoflehner@apple.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Kevin,<div><br></div>
<div>I assume you are using gcc as your build compiler? At least in gcc v4.9 there seems an issue with the register allocator resulting in a stack overwrite in the target independent part of the machine combiner:</div><div>
<br></div><div>MachineCombiner.cpp:</div><div><div style="margin:0px;font-family:Menlo;color:rgb(83,48,225)">/// preservesResourceLen - True when the new instructions do not increase</div><div style="margin:0px;font-family:Menlo;color:rgb(83,48,225)">
/// resource length</div><div style="margin:0px;font-family:Menlo;color:rgb(83,48,225)">...</div><div style="margin:0px;font-family:Menlo;min-height:21px">>>> Allocate ptr to MBB on the stack</div><div style="margin:0px;font-family:Menlo">
ArrayRef<<span style="color:rgb(52,189,38)">const</span> MachineBasicBlock *> MBBarr(MBB);</div><div style="margin:0px;font-family:Menlo"> <span style="color:rgb(52,189,38)">unsigned</span> ResLenBeforeCombine = BlockTrace.getResourceLength(MBBarr);</div>
</div></div></blockquote><div><br></div><div>I'm using gcc 4.8.2, and I can reproduce similar issue. I can't find source code issue, but for the above two line of source code, I can see gcc is generate the following assembly code,</div>
<div><br></div><div><div>276 ArrayRef<const MachineBasicBlock *> MBBarr(MBB);</div><div>00007ffff5f468c3: mov -0x1a0(%rbp),%rax</div><div>00007ffff5f468ca: mov %rax,-0x160(%rbp)</div><div>00007ffff5f468d1: lea -0x160(%rbp),%rdx <b>// get the address of the 1st argument</b></div>
<div>00007ffff5f468d8: lea -0x180(%rbp),%rax</div><div>00007ffff5f468df: mov %rdx,%rsi</div><div>00007ffff5f468e2: mov %rax,%rdi</div><div>00007ffff5f468e5: callq 0x7ffff5f477b8 <llvm::ArrayRef<llvm::MachineBasicBlock const*>::ArrayRef(llvm::MachineBasicBlock const* const&)> <b>// initialize MBBarr</b></div>
<div>277 unsigned ResLenBeforeCombine = BlockTrace.getResourceLength(MBBarr);</div><div>00007ffff5f468ea: lea -0x160(%rbp),%rax <b> // get the address of the 2nd argument, but it is overlapped with the 1st one.</b></div>
<div>00007ffff5f468f1: mov $0x0,%esi</div><div>00007ffff5f468f6: mov %rax,%rdi</div><div>00007ffff5f468f9: callq 0x7ffff5e86cf0 <llvm::ArrayRef<llvm::MCSchedClassDesc const*>::ArrayRef(llvm::NoneType)></div>
<div>00007ffff5f468fe: lea -0x170(%rbp),%rax <b>// get the address of the 3rd argument</b></div><div>00007ffff5f46905: mov $0x0,%esi</div><div>00007ffff5f4690a: mov %rax,%rdi</div><div>00007ffff5f4690d: callq 0x7ffff5e86cf0 <llvm::ArrayRef<llvm::MCSchedClassDesc const*>::ArrayRef(llvm::NoneType)></div>
<div>00007ffff5f46912: mov -0x170(%rbp),%rcx</div><div>00007ffff5f46919: mov -0x168(%rbp),%r8</div><div>00007ffff5f46920: mov -0x180(%rbp),%rsi</div><div>00007ffff5f46927: mov -0x178(%rbp),%r9</div><div>00007ffff5f4692e: lea -0x1b0(%rbp),%rdi</div>
<div>00007ffff5f46935: mov -0x160(%rbp),%rax</div><div>00007ffff5f4693c: mov -0x158(%rbp),%rdx</div><div>00007ffff5f46943: mov %rax,(%rsp)</div><div>00007ffff5f46947: mov %rdx,0x8(%rsp)</div><div>00007ffff5f4694c: mov %r9,%rdx</div>
<div>00007ffff5f4694f: callq 0x7ffff5df0a60 <_ZNK4llvm19MachineTraceMetrics5Trace17<b>getResourceLength</b>ENS_8ArrayRefIPKNS_17MachineBasicBlockEEENS2_IPKNS_16MCSchedClassDescEEESA_@plt></div></div><div><br></div>
<div>And here obviously, the address -0x160(%rbp) passed to function getResourceLength as the 1st argument is overwritten by the initialization code of the 2nd parameter inside the function. <br></div><div><br></div><div>
So it looks like a gcc bug. What gcc version are you using in your local box? I'm thinking if we should use clang/llvm bootstrap, rather than using gcc to build clang/llvm any longer.</div><div><br></div><div>Any thoughts?<br>
</div><div><br></div><div>Thanks,</div><div>-Jiangning</div></div></div></div>
</blockquote></div><br></div></body></html>