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

CodeGen/X86/xmm-r64.ll failure on non-x86-64 hosts #1382

Closed
nlewycky opened this issue Nov 19, 2006 · 3 comments
Closed

CodeGen/X86/xmm-r64.ll failure on non-x86-64 hosts #1382

nlewycky opened this issue Nov 19, 2006 · 3 comments
Assignees
@lattner
Labels
backend:X86 bugzilla Issues migrated from bugzilla compile-fail Use [accepts-invalid] and [rejects-valid] instead

Comments

@nlewycky
Copy link
Contributor

Bugzilla Link 1010
Resolution FIXED
Resolved on Feb 22, 2010 12:45
Version trunk
OS Linux

Extended Description

Regression/CodeGen/X86/xmm-r64.ll has regressed:

$ llvm/Debug/bin/llvm-as <
/home/nicholas/llvm-commit/test/Regression/CodeGen/X86/xmm-r64.ll |
llvm/Debug/bin/llc -march=x86-64
Warning: Generation of 64-bit code for a 32-bit processor requested.
llc: SelectionDAGISel.cpp:1775: void
llvm::SelectionDAGLowering::visitTargetIntrinsic(llvm::CallInst&, unsigned int):
Assertion `TLI.isTypeLegal(Op.getValueType()) && "Intrinsic uses a non-legal
type?"' failed.
llvm/Debug/bin/llc((anonymous namespace)::PrintStackTrace()+0x1a)[0x8814248]
llvm/Debug/bin/llc((anonymous namespace)::SignalHandler(int)+0x110)[0x881450c]
[0xffffe500]
Aborted

Not bugpointing because it's already a reduced testcase.
@nlewycky
Copy link
Contributor Author

assigned to @lattner

@nlewycky
Copy link
Contributor Author

Backtrace:

(gdb) bt
#​0 0xffffe405 in __kernel_vsyscall ()
#​1 0xf7d3f811 in raise () from /lib/tls/i686/cmov/libc.so.6
#​2 0xf7d40fb9 in abort () from /lib/tls/i686/cmov/libc.so.6
#​3 0xf7d38fbf in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
#​4 0x085c5d3e in llvm::SelectionDAGLowering::visitTargetIntrinsic (
this=0xffc65e48, I=@0x891f420, Intrinsic=272) at SelectionDAGISel.cpp:1774
#​5 0x085c6308 in llvm::SelectionDAGLowering::visitIntrinsicCall (
this=0xffc65e48, I=@0x891f420, Intrinsic=272) at SelectionDAGISel.cpp:1836
#​6 0x085c7846 in llvm::SelectionDAGLowering::visitCall (this=0xffc65e48,
I=@0x891f420) at SelectionDAGISel.cpp:2019
#​7 0x085e3bd4 in llvm::SelectionDAGLowering::visit (this=0xffc65e48,
Opcode=33, I=@0x891f420)
at /home/nicholas/llvm/include/llvm/Instruction.def:131
#​8 0x085e3cd2 in llvm::SelectionDAGLowering::visit (this=0xffc65e48,
I=@0x891f420) at SelectionDAGISel.cpp:457
#​9 0x085cccb4 in llvm::SelectionDAGISel::BuildSelectionDAG (this=0x89223e0,
DAG=@0xffc660a4, LLVMBB=0x891c110, PHINodesToUpdate=@0xffc66160,
FuncInfo=@0xffc66200) at SelectionDAGISel.cpp:3811
#​10 0x085cd6d8 in llvm::SelectionDAGISel::SelectBasicBlock (this=0x89223e0,
LLVMBB=0x891c110, MF=@0x8925428, FuncInfo=@0xffc66200)
at SelectionDAGISel.cpp:3974
#​11 0x085cec7e in llvm::SelectionDAGISel::runOnFunction (this=0x89223e0,
Fn=@0x891cc30) at SelectionDAGISel.cpp:3686
#​12 0x084a9193 in (anonymous namespace)::X86DAGToDAGISel::runOnFunction (
this=0x89223e0, Fn=@0x891cc30) at X86ISelDAGToDAG.cpp:124
#​13 0x08798f91 in llvm::FunctionPassManagerT::runPass (this=0x891ef08,
P=0x89223e0, F=0x891cc30) at PassManagerT.h:804
#​14 0x087ae438 in llvm::PassManagerTllvm::FTraits::runPasses (
this=0x891ef20, M=0x891cc30, LastUserOf=@0xffc6636c) at PassManagerT.h:596
#​15 0x087aee48 in llvm::PassManagerTllvm::FTraits::runOnUnit (
this=0x891ef20, M=0x891cc30) at PassManagerT.h:282
#​16 0x08799073 in llvm::FunctionPassManagerT::runOnFunction (this=0x891ef08,
F=@0x891cc30) at PassManagerT.h:896
#​17 0x08798d89 in llvm::FunctionPassManager::run (this=0xffc6644c,
F=@0x891cc30) at Pass.cpp:110
#​18 0x083a2524 in main (argc=3, argv=0xffc66534) at llc.cpp:262

@lattner
Copy link
Collaborator

lattner commented Nov 20, 2006

Fixed, patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061120/040137.html

-Chris

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
clementval pushed a commit to clementval/llvm-project that referenced this issue Jan 17, 2022
@jeanPerier
Support calling character functions with only the result is being exp…
375d9f9 
…licit (llvm#1382)

When calling a character function, the result is allocated on the caller
side. The current code was assuming that there would be an interface
when calling these kinds of function. This is not entirely correct, for
scalar character function, the result type may be explicitly defined
while the rest of the function interface is still implicit.
Support this case by relaxing an assert and avoid requiring result
symbol mapping if there is no interface (and hence no mapping to do
with a result symbol belonging to an interface).
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
backend:X86 bugzilla Issues migrated from bugzilla compile-fail Use [accepts-invalid] and [rejects-valid] instead
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@nlewycky @lattner