Well, it really shouldn't be done that way, but we shouldn't crash either.

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.

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.

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

@ 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 ?

See the discussion on llvmdev; gcc's behavior is weird, but consistent in a usable way for this particular case.

Yet another testcase -target armv7-linux-gnueabihf:
void check_vect (void)
{
long long a = 0;
asm ("vorr %P0" :"=w" (a) : "0" (a));
}

https://reviews.llvm.org/D35587 proposed a fix but hasn't been touched for years