Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

Inline assembly referencing a local goto label without any labels given crashes LLVM #37691

Open Quuxplusone opened 6 years ago

Quuxplusone commented 6 years ago
Bugzilla Link PR38718
Status NEW
Importance P normal
Reported by Emil Gedda (emil.gedda@emilgedda.se)
Reported on 2018-08-27 03:00:29 -0700
Last modified on 2018-08-28 06:08:13 -0700
Version 6.0
Hardware PC Linux
CC francisvm@yahoo.com, llvm-bugs@lists.llvm.org, rnk@google.com
Fixed by commit(s)
Attachments bugpoint-reduced-simplified.ll (533 bytes, text/plain)
Blocks
Blocked by
See also
Created attachment 20776
crashing example

Trying to use "outs %l0 %w1" in inline assembly crashes LLVM.
The culprit in this case is the "%l0" which references a goto label when none
was given.

How to reproduce:
   See below

Expected behaviour:
   An error explaining that you cant reference labels using "%l" without the goto qualifier on the inline assembly,
   and if possible tell the user "did you forget the goto qualifier?" (even though goto qualifiers are not supported yet).

Actual behaviour:
   Compiling with clang++ and without optimizations segfaults LLVM, with optimizations it crashes with out of memory.
   Compiling directly with llc gives "No such file or directory", and then segfaults.

Repro:

 $ cat bugpoint-reduced-simplified.ll
 ; ModuleID = 'bugpoint-reduced-simplified.bc'
 source_filename = "bugpoint-output-9760709.bc"
 target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-pc-linux-gnu"

 ; Function Attrs: norecurse nounwind optsize sspstrong uwtable
 define void @main() local_unnamed_addr #0 {
  tail call void asm sideeffect "outs ${0:l}, ${1:w}", "{ax},N{dx},~{dirflag},~{fpsr},~{flags}"(i8* null, i32 0) #1, !srcloc !1
  ret void
 }

 !llvm.ident = !{!0}

 !0 = !{!"clang version 6.0.1 (tags/RELEASE_601/final)"}
 !1 = !{i32 26}

 $ llc bugpoint-reduced-simplified.ll
 LLVMSymbolizer: error reading file: No such file or directory
 #0 0x00007f8d747157cb llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/bin/../lib/libLLVM-6.0.so+0x8517cb)
 #1 0x00007f8d747134be llvm::sys::RunSignalHandlers() (/usr/bin/../lib/libLLVM-6.0.so+0x84f4be)
 #2 0x00007f8d7471372b (/usr/bin/../lib/libLLVM-6.0.so+0x84f72b)
 #3 0x00007f8d73ba8e00 __restore_rt (/usr/bin/../lib/libc.so.6+0x37e00)
 #4 0x00007f8d7499b3dc llvm::MachineBasicBlock::getSymbol() const (/usr/bin/../lib/libLLVM-6.0.so+0xad73dc)
 #5 0x00007f8d74dc5c32 llvm::AsmPrinter::EmitInlineAsm(llvm::MachineInstr const*) const (/usr/bin/../lib/libLLVM-6.0.so+0xf01c32)
 #6 0x00007f8d74dba824 llvm::AsmPrinter::EmitFunctionBody() (/usr/bin/../lib/libLLVM-6.0.so+0xef6824)
 #7 0x00007f8d763926bd (/usr/bin/../lib/libLLVM-6.0.so+0x24ce6bd)
 #8 0x00007f8d749e66d0 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/usr/bin/../lib/libLLVM-6.0.so+0xb226d0)
 #9 0x00007f8d747fbaf8 llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/bin/../lib/libLLVM-6.0.so+0x937af8)
 #10 0x00007f8d747fbb72 llvm::FPPassManager::runOnModule(llvm::Module&) (/usr/bin/../lib/libLLVM-6.0.so+0x937b72)
 #11 0x00007f8d747fb204 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/bin/../lib/libLLVM-6.0.so+0x937204)
 #12 0x000055bb7b65d63d (llc+0x2163d)
 #13 0x000055bb7b651d65 (llc+0x15d65)
 #14 0x00007f8d73b95223 __libc_start_main (/usr/bin/../lib/libc.so.6+0x24223)
 #15 0x000055bb7b651f3e (llc+0x15f3e)
 Stack dump:
 0. Program arguments: llc bugpoint-reduced-simplified.ll
 1. Running pass 'Function Pass Manager' on module 'bugpoint-reduced-simplified.ll'.
 2. Running pass 'X86 Assembly Printer' on function '@main'
 [1]    7997 segmentation fault (core dumped)  llc bugpoint-reduced-simplified.ll
Quuxplusone commented 6 years ago

Attached bugpoint-reduced-simplified.ll (533 bytes, text/plain): crashing example

Quuxplusone commented 6 years ago

Can you provide a small C test case as well? Personally I think bugpoint often overreduces problems.

Quuxplusone commented 6 years ago
> Can you provide a small C test case as well?
> Personally I think bugpoint often overreduces problems.

Sure, no problem.

int main() {
  __asm__ ("outs %l0, %w1" :: "a" ((void*)0), "Nd" (0));
}