Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Inline asm crash #1686

Closed
llvmbot opened this issue Apr 7, 2007 · 8 comments
Closed

Inline asm crash #1686

llvmbot opened this issue Apr 7, 2007 · 8 comments
Assignees
@lattner
Labels
bugzilla Issues migrated from bugzilla compile-fail Use [accepts-invalid] and [rejects-valid] instead llvm:codegen

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented Apr 7, 2007

Bugzilla Link 1314
Resolution FIXED
Resolved on Feb 22, 2010 12:54
Version trunk
OS Linux
Blocks #1234
Attachments Original bytecode file that caused assertion failure with llc, Bytecode produced by bugpoint, Stdout and stderr from running bugpoint
Reporter LLVM Bugzilla Contributor

Extended Description

I am getting an assertion failure when I run "llc -f -o /dev/null code.bc"
code.bc has been formed by linking other bytecode files that were all generated
by llvm-gcc and transformed using opt. All uses of opt passed the -verify option.

I ran llc in gdb and it stops with:

llc:
/home/data2/lefever/work/llvm-cvs-070306/include/llvm/Support/Casting.h:199:
typename llvm::cast_retty<To, From>::ret_type llvm::cast(const Y&) [with X =
llvm::ConstantSDNode, Y = llvm::SDOperand]: Assertion `isa(Val) &&
"cast() argument of incompatible type!"' failed.

The stack trace at that point is:

(gdb) bt
#​0 0x0000003de682e37d in raise () from /lib64/tls/libc.so.6
#​1 0x0000003de682faae in abort () from /lib64/tls/libc.so.6
#​2 0x0000003de6827c31 in __assert_fail () from /lib64/tls/libc.so.6
#​3 0x000000000082829c in llvm::cast<llvm::ConstantSDNode, llvm::SDOperand>
(Val=@0x166eb20) at
/home/data2/lefever/work/llvm-cvs-070306/include/llvm/Support/Casting.h:199
#​4 0x0000000000a6b18d in llvm::ScheduleDAG::EmitNode (this=0x1660180,
Node=0x1672330, VRBaseMap=@0x7fbfffe5e0) at ScheduleDAG.cpp:543
#​5 0x0000000000a6b67b in llvm::ScheduleDAG::EmitSchedule (this=0x1660180) at
ScheduleDAG.cpp:616
#​6 0x00000000009e4e16 in (anonymous namespace)::ScheduleDAGRRList::Schedule
(this=0x1660180) at ScheduleDAGRRList.cpp:114
#​7 0x0000000000a6b7e9 in llvm::ScheduleDAG::Run (this=0x1660180) at
ScheduleDAG.cpp:644
#​8 0x0000000000a18c1c in llvm::SelectionDAGISel::ScheduleAndEmitDAG
(this=0x1011d20, DAG=@0x7fbfffec70) at SelectionDAGISel.cpp:4528
#​9 0x00000000008d6052 in (anonymous
namespace)::X86DAGToDAGISel::InstructionSelectBasicBlock (this=0x1011d20,
DAG=@0x7fbfffec70) at X86ISelDAGToDAG.cpp:476
#​10 0x0000000000a1823d in llvm::SelectionDAGISel::CodeGenAndEmitDAG
(this=0x1011d20, DAG=@0x7fbfffec70) at SelectionDAGISel.cpp:4387
#​11 0x0000000000a18317 in llvm::SelectionDAGISel::SelectBasicBlock
(this=0x1011d20, LLVMBB=0x12780c0, MF=@0x15ee620, FuncInfo=@0x7fbfffee50) at
SelectionDAGISel.cpp:4405
#​12 0x0000000000a16958 in llvm::SelectionDAGISel::runOnFunction (this=0x1011d20,
Fn=@0x1058130) at SelectionDAGISel.cpp:4090
#​13 0x000000000098b6a9 in (anonymous namespace)::X86DAGToDAGISel::runOnFunction
(this=0x1011d20, Fn=@0x1058130) at X86ISelDAGToDAG.cpp:122
#​14 0x0000000000bd90b2 in llvm::FPPassManager::runOnFunction (this=0x1013020,
F=@0x1058130) at PassManager.cpp:1047
#​15 0x0000000000bd8e7c in llvm::FunctionPassManagerImpl::run (this=0x119be60,
F=@0x1058130) at PassManager.cpp:1006
#​16 0x0000000000bd8d76 in llvm::FunctionPassManager::run (this=0x7fbffff1d0,
F=@0x1058130) at PassManager.cpp:951
#​17 0x00000000007bd037 in main (argc=5, argv=0x7fbffff338) at llc.cpp:290
@llvmbot
Copy link
Collaborator Author

llvmbot commented Apr 7, 2007

assigned to @lattner

@llvmbot
Copy link
Collaborator Author

llvmbot commented Apr 7, 2007

I ran bugpoint on the original bytecode file that caused llc to fail with an
assertion. I have attached the original bytecode file causing the assertion,
the bytecode file produced by bugpoint, and a text file with the output from
bugpoint.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Apr 7, 2007

Thank you for the complete bug report, Ryan.

On the Head, the problem is actually offset a few lines at ScheduleDAG.cpp:557

  // Add all of the operand registers to the instruction.
  for (unsigned i = 2; i != NumOps;) {
    unsigned Flags = cast<ConstantSDNode>(Node->getOperand(i))->getValue();
    unsigned NumVals = Flags >> 3;

The cast to ConstantSDNode is not correct in this case as the node's operand is
actually an SDOperand. I'm not sure what this should be (other than SDOperand),
but its probably obvious to Chris or Evan.

Can you try cast(...) instead ?

@llvmbot
Copy link
Collaborator Author

llvmbot commented Apr 7, 2007

P.S. The bugpoint run was inconclusive (it failed).

@llvmbot
Copy link
Collaborator Author

llvmbot commented Apr 7, 2007

Ryan,

Actually, don't bother. It doesn't compile. I'm not sure what the right solution
here is.

Reid.

@lattner
Copy link
Collaborator

lattner commented Apr 9, 2007

reduced testcase:

target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-
v64:64:64-v128:128:128-a0:0:64"
target triple = "x86_64-unknown-linux-gnu"
%struct.CycleCount = type { i64, i64 }
%struct.bc_struct = type { i32, i32, i32, i32, %struct.bc_struct*, i8*, i8* }
@​_programStartTime = external global %struct.CycleCount ; <%struct.CycleCount*> [#uses=1]

define fastcc i32 @​bc_divide(%struct.bc_struct* %n1, %struct.bc_struct* %n2, %struct.bc_struct** %quot,
i32 %scale) {
entry:
br i1 false, label %cond_next60, label %UnifiedReturnBlock86

cond_next60: ; preds = %entry
br i1 false, label %cond_next155, label %cond_next81.preheader

cond_next81.preheader: ; preds = %cond_next60
ret i32 0

cond_next155: ; preds = %cond_next60
%tmp7.i46 = tail call i64 asm sideeffect ".byte 0x0f,0x31", "={dx},=={ax},{dirflag},{fpsr},~
{flags}"( i64* getelementptr (%struct.CycleCount* @​_programStartTime, i32 0, i32 1) ) ;
[#uses=0]
%tmp221 = sdiv i32 10, 0 ; [#uses=1]
tail call fastcc void @​_one_mult( i8* null, i32 0, i32 %tmp221, i8* null )
ret i32 0

UnifiedReturnBlock86: ; preds = %entry
ret i32 -1
}

declare fastcc void @​_one_mult(i8*, i32, i32, i8*)

@lattner
Copy link
Collaborator

lattner commented Apr 9, 2007

Fixed, testcase here: CodeGen/X86/2007-04-08-InlineAsmCrash.ll

Patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070402/047028.html

Thanks!

-Chris

@asl
Copy link
Collaborator

asl commented Nov 27, 2021

mentioned in issue #1234

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
troelsbjerre pushed a commit to troelsbjerre/llvm-project that referenced this issue Jan 10, 2024
@shahmishal
Merge pull request llvm#1686 from JDevlieghere/🍒/bastille/dotest-buil…
a27303c 
…der-refactoring

LLDB builder refactoring
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@lattner lattner

Labels
bugzilla Issues migrated from bugzilla compile-fail Use [accepts-invalid] and [rejects-valid] instead llvm:codegen
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@asl @lattner @llvmbot