<div dir="ltr">Yeah, I can do that (though I probably won't get to it until Monday). Thanks for coming up with the patch!</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Apr 12, 2014 at 4:25 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">getAccessVariant is fairly incomplete. The attached patch should fix this case.<br>
<br>
"Unfortunately" I will be on vacations next week and mostly out of the<br>
internet during that time. Can you commit the patch if it does fix the<br>
issue for you? I will try to write a more complete version when I get<br>
back (on the 20th).<br>
<div class="HOEnZb"><div class="h5"><br>
On 12 April 2014 00:50, Kaelyn Takata <<a href="mailto:rikka@google.com">rikka@google.com</a>> wrote:<br>
> On Thu, Mar 20, 2014 at 9:35 AM, Alexander Kornienko <<a href="mailto:alexfh@google.com">alexfh@google.com</a>><br>
> wrote:<br>
>><br>
>> On Thu, Mar 20, 2014 at 5:23 PM, Rafael Espíndola<br>
>> <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br>
>>><br>
>>> On 20 March 2014 04:58, Alexander Kornienko <<a href="mailto:alexfh@google.com">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>
>>> Open source place? I do have a build with compiler-rt in a linux vm<br>
>>><br>
>>> that I can use to reproduce the problem.<br>
>><br>
>><br>
>> Actually, I don't have a reliable repro. It shows as a linking error:<br>
>><br>
>> <some file>.o: requires unsupported dynamic reloc 14; recompile with -fPIC<br>
><br>
><br>
> I have narrowed down the source of the problem within r204293, affecting the<br>
> integrated assembler:<br>
><br>
> --- llvm/trunk/lib/Target/X86/MCTargetDesc/X86ELFObjectWriter.cpp (original)<br>
> +++ llvm/trunk/lib/Target/X86/MCTargetDesc/X86ELFObjectWriter.cpp Wed Mar 19<br>
> 21:12:01 2014<br>
> @@ -46,8 +46,7 @@ unsigned X86ELFObjectWriter::GetRelocTyp<br>
>                                            int64_t Addend) const {<br>
>    // determine the type of the relocation<br>
><br>
> -  MCSymbolRefExpr::VariantKind Modifier = Target.isAbsolute() ?<br>
> -    MCSymbolRefExpr::VK_None : Target.getSymA()->getKind();<br>
> +  MCSymbolRefExpr::VariantKind Modifier = Fixup.getAccessVariant();<br>
>    unsigned Type;<br>
>    if (getEMachine() == ELF::EM_X86_64) {<br>
>      if (IsPCRel) {<br>
><br>
> In the failing case, Fixup.getAccessVariant() is hitting the<br>
> llvm_unreachable... but the bad reloc happens due to the undefined behavior<br>
> of llvm_unreachable in an optimized build with assertions disabled. The<br>
> offending code was the gfortran-generated assembly of zgbtrf.f from lapack<br>
> (both 3.3.1 and 3.5.0 were hitting the problem, at least with -fPIC enabled)<br>
> being passed to clang.<br>
><br>
> I've narrowed down the assembly to a one-line test case. (FYI, "work13.1909"<br>
> was the name of a local variable in the original generated assembly, but not<br>
> having it defined at all doesn't affect the results; either way there should<br>
> be one relocation of type R_X86_64_PC32.)<br>
><br>
> $ cat zgbtrf.S<br>
>         leaq    -1040+work13.1909(%rip), %r11<br>
><br>
> $ build/bin/clang -cc1as -o x.o zgbtrf.S -triple x86_64-unknown-linux-gnu<br>
> -filetype obj -target-cpu x86-64<br>
> unsupported<br>
> UNREACHABLE executed at llvm/lib/MC/MCFixup.cpp:17!<br>
> 0  clang           0x0000000001811a4e llvm::sys::PrintStackTrace(_IO_FILE*)<br>
> + 46<br>
> 1  clang           0x0000000001811d0b<br>
> 2  clang           0x0000000001811f7e<br>
> 3  libpthread.so.0 0x00007f28707bfcb0<br>
> 4  libc.so.6       0x00007f286f9fa425 gsignal + 53<br>
> 5  libc.so.6       0x00007f286f9fdb8b abort + 379<br>
> 6  clang           0x00000000017d1246<br>
> 7  clang           0x0000000003aaa523<br>
> 8  clang           0x0000000003aaa5ab<br>
> 9  clang           0x0000000003aaa5ab<br>
> 10 clang           0x0000000003aaa4bd llvm::MCFixup::getAccessVariant()<br>
> const + 29<br>
> 11 clang           0x0000000001bda04f<br>
> 12 clang           0x0000000003a9c2e2<br>
> 13 clang           0x0000000003a94255<br>
> 14 clang           0x0000000001601778<br>
> llvm::MCAssembler::handleFixup(llvm::MCAsmLayout const&, llvm::MCFragment&,<br>
> llvm::MCFixup const&) + 392<br>
> 15 clang           0x0000000001601cbc llvm::MCAssembler::Finish() + 1308<br>
> 16 clang           0x0000000003ab0c2d llvm::MCObjectStreamer::FinishImpl() +<br>
> 93<br>
> 17 clang           0x0000000003aa867a llvm::MCELFStreamer::FinishImpl() + 74<br>
> 18 clang           0x0000000001633526 llvm::MCStreamer::Finish() + 150<br>
> 19 clang           0x000000000163e32e<br>
> 20 clang           0x0000000000912dc5<br>
> 21 clang           0x0000000000910b19 cc1as_main(char const**, char const**,<br>
> char const*, void*) + 1033<br>
> 22 clang           0x0000000000905104 main + 996<br>
> 23 libc.so.6       0x00007f286f9e576d __libc_start_main + 237<br>
> 24 clang           0x0000000000904bc5<br>
><br>
><br>
</div></div></blockquote></div><br></div>