<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 20, 2014 at 9:35 AM, Alexander Kornienko <span dir="ltr"><<a href="mailto:alexfh@google.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=alexfh@google.com&cc=&bcc=&su=&body=','_blank');return false;" class="cremed">alexfh@google.com</a>></span> wrote:<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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div class="">On Thu, Mar 20, 2014 at 5:23 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=rafael.espindola@gmail.com&cc=&bcc=&su=&body=','_blank');return false;" class="cremed">rafael.espindola@gmail.com</a>></span> wrote:<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>On 20 March 2014 04:58, Alexander Kornienko <<a href="mailto:alexfh@google.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=alexfh@google.com&cc=&bcc=&su=&body=','_blank');return false;" class="cremed">alexfh@google.com</a>> wrote:<br>
> Either this revision or r204293 breaks something again (in a different<br>
> place, though). I'll post details once I have more information.<br>
<br>
</div>Open source place? I do have a build with compiler-rt in a linux vm </blockquote><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">
that I can use to reproduce the problem.<br></blockquote><div><br></div></div><div>Actually, I don't have a reliable repro. It shows as a linking error:</div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div class="gmail_extra"><div class="gmail_quote"><div><some file>.o: requires unsupported dynamic reloc 14; recompile with -fPIC</div></div></div></blockquote></div></blockquote><div><br></div><div>I have narrowed down the source of the problem within r204293, affecting the integrated assembler:</div>
<div><br></div><div><div>--- llvm/trunk/lib/Target/X86/MCTargetDesc/X86ELFObjectWriter.cpp (original)</div><div>+++ llvm/trunk/lib/Target/X86/MCTargetDesc/X86ELFObjectWriter.cpp Wed Mar 19 21:12:01 2014</div><div>@@ -46,8 +46,7 @@ unsigned X86ELFObjectWriter::GetRelocTyp</div>
<div> int64_t Addend) const {</div><div> // determine the type of the relocation</div><div><br></div><div>- MCSymbolRefExpr::VariantKind Modifier = Target.isAbsolute() ?</div><div>
- MCSymbolRefExpr::VK_None : Target.getSymA()->getKind();</div><div>+ MCSymbolRefExpr::VariantKind Modifier = Fixup.getAccessVariant();</div><div> unsigned Type;</div><div> if (getEMachine() == ELF::EM_X86_64) {</div>
<div> if (IsPCRel) {</div></div><div><br></div><div>In the failing case, Fixup.getAccessVariant() is hitting the llvm_unreachable... but the bad reloc happens due to the undefined behavior of llvm_unreachable in an optimized build with assertions disabled. The offending code was the gfortran-generated assembly of zgbtrf.f from lapack (both 3.3.1 and 3.5.0 were hitting the problem, at least with -fPIC enabled) being passed to clang.</div>
<div><br></div><div>I've narrowed down the assembly to a one-line test case. (FYI, "work13.1909" was the name of a local variable in the original generated assembly, but not having it defined at all doesn't affect the results; either way there should be one relocation of type R_X86_64_PC32.)</div>
<div><br></div><div><div>$ cat zgbtrf.S </div><div> leaq -1040+work13.1909(%rip), %r11<br></div></div><div><br></div><div>$ build/bin/clang -cc1as -o x.o zgbtrf.S -triple x86_64-unknown-linux-gnu -filetype obj -target-cpu x86-64</div>
<div>unsupported</div><div>UNREACHABLE executed at llvm/lib/MC/MCFixup.cpp:17!</div><div>0 clang 0x0000000001811a4e llvm::sys::PrintStackTrace(_IO_FILE*) + 46</div><div>1 clang 0x0000000001811d0b</div>
<div>2 clang 0x0000000001811f7e</div><div>3 libpthread.so.0 0x00007f28707bfcb0</div><div>4 libc.so.6 0x00007f286f9fa425 gsignal + 53</div><div>5 libc.so.6 0x00007f286f9fdb8b abort + 379</div><div>
6 clang 0x00000000017d1246</div><div>7 clang 0x0000000003aaa523</div><div>8 clang 0x0000000003aaa5ab</div><div>9 clang 0x0000000003aaa5ab</div><div>10 clang 0x0000000003aaa4bd llvm::MCFixup::getAccessVariant() const + 29</div>
<div>11 clang 0x0000000001bda04f</div><div>12 clang 0x0000000003a9c2e2</div><div>13 clang 0x0000000003a94255</div><div>14 clang 0x0000000001601778 llvm::MCAssembler::handleFixup(llvm::MCAsmLayout const&, llvm::MCFragment&, llvm::MCFixup const&) + 392</div>
<div>15 clang 0x0000000001601cbc llvm::MCAssembler::Finish() + 1308</div><div>16 clang 0x0000000003ab0c2d llvm::MCObjectStreamer::FinishImpl() + 93</div><div>17 clang 0x0000000003aa867a llvm::MCELFStreamer::FinishImpl() + 74</div>
<div>18 clang 0x0000000001633526 llvm::MCStreamer::Finish() + 150</div><div>19 clang 0x000000000163e32e</div><div><div>20 clang 0x0000000000912dc5</div><div>21 clang 0x0000000000910b19 cc1as_main(char const**, char const**, char const*, void*) + 1033</div>
<div>22 clang 0x0000000000905104 main + 996</div><div>23 libc.so.6 0x00007f286f9e576d __libc_start_main + 237</div><div>24 clang 0x0000000000904bc5</div></div><div><br></div><div><br></div></div>
</div></div>