llc asserts on given bitcode

[llvmbot]

Bugzilla Link	3551
Resolution	FIXED
Resolved on	Feb 12, 2009 12:48
Version	trunk
OS	MacOS X
Attachments	LLVM Assembly of Bitcode file
Reporter	LLVM Bugzilla Contributor

Extended Description

The llc tool asserts on the attached bitcode file. The stack trace is:

Cannot yet select: 0x1810398: ch = declare 0x170eae4, 0x181062c, 0x1810524

#​0 0x929d2b9e in __kill ()
#​1 0x929d2b91 in kill$UNIX2003 ()
#​2 0x92a49ec2 in raise ()
#​3 0x92a5947f in abort ()
#​4 0x00386f0f in (anonymous namespace)::X86DAGToDAGISel::CannotYetSelect (this=0x170e9a0, N={Node = 0x1810398, ResNo = 0}) at X86GenDAGISel.inc:52907
#​5 0x0039b6f1 in (anonymous namespace)::X86DAGToDAGISel::Select_DECLARE (this=0x170e9a0, N=@0xbfffedf4) at X86GenDAGISel.inc:51187
#​6 0x004b32ff in (anonymous namespace)::X86DAGToDAGISel::SelectCode (this=0x170e9a0, N={Node = 0x1810398, ResNo = 0}) at X86GenDAGISel.inc:51249
#​7 0x0031256c in (anonymous namespace)::X86DAGToDAGISel::Select (this=0x170e9a0, N={Node = 0x1810398, ResNo = 0}) at /Users/criswell/src/llvm22/lib/Target/X86/X86ISelDAGToDAG.cpp:1588
#​8 0x004b7557 in (anonymous namespace)::X86DAGToDAGISel::SelectRoot (this=0x170e9a0, DAG=@0x170ead0) at DAGISelHeader.h:119
#​9 0x00315105 in (anonymous namespace)::X86DAGToDAGISel::InstructionSelect (this=0x170e9a0) at /Users/criswell/src/llvm22/lib/Target/X86/X86ISelDAGToDAG.cpp:709
#​10 0x005e1e44 in llvm::SelectionDAGISel::CodeGenAndEmitDAG (this=0x170e9a0) at /Users/criswell/src/llvm22/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:656
#​11 0x005e3b17 in llvm::SelectionDAGISel::SelectBasicBlock (this=0x170e9a0, LLVMBB=0x170bc20, Begin={<bidirectional_iteratorllvm::Instruction,ptrdiff_t> = {<> = {}, }, NodePtr = 0x170bf64}, End={<bidirectional_iteratorllvm::Instruction,ptrdiff_t> = {<> = {}, }, NodePtr = 0x170bf90}) at /Users/criswell/src/llvm22/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:500
#​12 0x005e4365 in llvm::SelectionDAGISel::SelectAllBasicBlocks (this=0x170e9a0, Fn=@0x1707a40, MF=@0x1714200, MMI=0x1712510, DW=0x170f210, TII=@0x18062f0) at /Users/criswell/src/llvm22/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:856
#​13 0x005e473c in llvm::SelectionDAGISel::runOnFunction (this=0x170e9a0, Fn=@0x1707a40) at /Users/criswell/src/llvm22/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:327
#​14 0x0086091c in llvm::FPPassManager::runOnFunction (this=0x170c7f0, F=@0x1707a40) at /Users/criswell/src/llvm22/lib/VMCore/PassManager.cpp:1323
#​15 0x00860b72 in llvm::FunctionPassManagerImpl::run (this=0x170c610, F=@0x1707a40) at /Users/criswell/src/llvm22/lib/VMCore/PassManager.cpp:1281
#​16 0x00860cf8 in llvm::FunctionPassManager::run (this=0xbffff5e0, F=@0x1707a40) at /Users/criswell/src/llvm22/lib/VMCore/PassManager.cpp:1226
#​17 0x00002dc5 in main (argc=2, argv=0xbffff694) at /Users/criswell/src/llvm22/tools/llc/llc.cpp:317

[llvmbot]

Hi John,

How was this .ll file created? Was it via clang?

[llvmbot]

This was generated via an older (i.e., not recently updated to mainline) version of llvm-gcc 4.2. The test case is a reduced test case from Bonjour.

[lattner]

devang, do you see anything obviously wrong with this?

[llvmbot]

Chris,

Your rev. 64382 patch fixed this. Thanks!