<div dir="ltr">Hi Gerolf,<div><br></div><div>The buildbot at <a href="http://lab.llvm.org:8011/builders/clang-aarch64-lnt/builds/735">http://lab.llvm.org:8011/builders/clang-aarch64-lnt/builds/735</a> is using gcc 4.8.3, but somehow lnt test can all pass. I'm confused around this, because<br>
</div><div><br></div><div>gcc 4.8.2: fail (I tried)</div><div>gcc 4.8.3: pass (Gabor is the maintainer of this buildbot, and he told me this buildbot is using gcc 4.8.3)</div><div>gcc 4.9: fail (You tried)</div><div><br></div>
<div>But they are all on different machines, so it's hard to tell root cause.</div><div><br></div><div>Actually, this is not the only gcc issue we encountered so far. We found another gcc issue causing clang/llvm *release* version failure, and it's hard to be reproduced with a small test case.</div>
<div><br></div><div>So is it possible to migrate all build bots to clang for all targets in future?</div><div><br></div><div>Thanks,</div><div>-Jiangning</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
2014-08-07 3:37 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">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><span class="HOEnZb"><font color="#888888"><div>Gerolf</div></font></span><div><div class="h5"><div><br></div><div><br><div><div>On Aug 6, 2014, at 12:35 AM, Jiangning Liu <<a href="mailto:liujiangning1@gmail.com" target="_blank">liujiangning1@gmail.com</a>> wrote:</div>
<br><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></div></div></div></blockquote></div><br></div>