LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 14393 - codegen crash with inline asm
Summary: codegen crash with inline asm
Status: NEW
Alias: None
Product: libraries
Classification: Unclassified
Component: Backend: X86 (show other bugs)
Version: trunk
Hardware: PC Linux
: P enhancement
Assignee: Konstantin Belochapka
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-20 15:07 PST by Rafael Ávila de Espíndola
Modified: 2019-12-23 21:28 PST (History)
10 users (show)

See Also:
Fixed By Commit(s):


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rafael Ávila de Espíndola 2012-11-20 15:07:35 PST
Reported by rajesh viswabramana on llvmdev, I just converted the test to IL:

-------------------------------------------
target triple = "i386-unknown-linux-gnu"

define double @func1() {
entry:
  %0 = tail call double asm "", "=r,0,~{dirflag},~{fpsr},~{flags}"(double undef)
  ret double %0
}
--------------------------------------------

$ ./bin/llc test.ll
llc: /home/espindola/llvm/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:383: void getCopyToParts(llvm::SelectionDAG &, llvm::DebugLoc, llvm::SDValue, llvm::SDValue *, unsigned int, llvm::EVT, const llvm::Value *, ISD::NodeType): Assertion `(PartVT.isInteger() || PartVT == MVT::x86mmx) && ValueVT.isInteger() && "Unknown mismatch!"' failed.
Comment 1 Eric Christopher 2012-11-20 15:12:33 PST
Well, it really shouldn't be done that way, but we shouldn't crash either.
Comment 2 viswabramana.rajesh 2012-11-21 04:00:42 PST
I found similar bug already reported, Closed

http://llvm.org/bugs/show_bug.cgi?id=8363

As per last comments in bug 8363,

Eric Christopher 2011-06-29 13:16:29 CDT 
This appears to be fixed from the front end side of things.

But issue still present.
Comment 3 Eli Friedman 2012-11-21 17:11:03 PST
There isn't any possible way we can generate sane code for this; "r" means an integer register, and a 64-bit value can't fit into a 32-bit register.  That said, both clang and the LLVM backend should be taught to generate a proper error message.
Comment 4 viswabramana.rajesh 2012-11-22 03:29:25 PST
I tried same code with gcc on arm with hard float,

double f2 ()
{
double x = 10.0;
asm ("" : "=r" (x) : "0" (x));
return x;
}

> arm-linux-gnueabi-gcc -S -mhard-float pr39058.c -O2

Generates proper code,
	mov	r3, #0
	mov	r2, #0
	movt	r3, 16420
	fmdrr	d0, r2, r3
	bx	lr
Comment 5 viswabramana.rajesh 2012-11-22 06:08:42 PST
@ Eli Friedman
 Could you please elobarate why generated code will be sane code if handled ?
 Is gcc also shouldn't handle this case ? 
 Is there some specific reason for not handling this in llvm ?
Comment 6 Eli Friedman 2012-11-24 19:20:51 PST
See the discussion on llvmdev; gcc's behavior is weird, but consistent in a usable way for this particular case.
Comment 7 Eugene Melekhov 2013-05-07 10:03:38 PDT
Yet another testcase -target armv7-linux-gnueabihf: 
void check_vect (void)
{
    long long a = 0;
    asm ("vorr %P0" :"=w" (a) : "0" (a));
}
Comment 8 Simon Pilgrim 2019-12-23 21:28:39 PST
https://reviews.llvm.org/D35587 proposed a fix but hasn't been touched for years