clang crash on "x" constraint for athlon-xp

Bruce Evans brde at
Fri May 24 08:07:08 UTC 2013

Why does clang -march=athlon-xp abort on this?

@ #include <xmmintrin.h>
@ void
@ foo(void)
@ {
@ 	__m128 x;
@ 	asm("" : "=x" (x));
@ }

@ SplitVectorResult #0: 0x2a190228: v16i8 = Register %vreg1 [ORD=1] [ID=0]
@ fatal error: error in backend: Do not know how to split the result of this operator!
@ cc: error: clang frontend command failed with exit code 70 (use -v to see invocation)
@ FreeBSD clang version 3.3 (trunk 178860) 20130405
@ Target: i386-unknown-freebsd10.0
@ Thread model: posix
@ cc: note: diagnostic msg: PLEASE submit a bug report to and include the crash backtrace, preprocessed source, and associated run script.
@ cc: note: diagnostic msg: 
@ ********************
@ Preprocessed source(s) and associated run script(s) are located at:
@ cc: note: diagnostic msg: /tmp/z-SmXpwL.c
@ cc: note: diagnostic msg: /tmp/
@ cc: note: diagnostic msg: 
@ ********************

clang also fills up /tmp with these files.

gcc -march=athlon-xp works, and so does clang -march=athlon64.

athlon64 has SSE1 and SSE2; athlon-xp only has SSE1.  The above is trying
to use only SSE1 features.

I don't really understand <xmmintrin.h> and am using it here just to
declare __m128.  Perhaps it can do what I want without any asm.  This
is to take an 8-byte double and split it into 2 integers using SSE*,
and vice versa.  SSE* must be used on 32-bit systems since compilers
still don't understand how to unpack and repack 64-bit objects efficiently
using integer instructions (loads and stores must be 64 bits).  I also
need this for 10-byte long doubles.  Raw asm is needed for 2 bytes of
these, and it would be hard to combine this with any intrinsics.

While here, I will re-report another clang asm problem:

@ 	double_t dt;
@ 	double d;
@ 	__asm("" : "=t" (d) : "0" (dt));

This works with gcc, but fails (generates a store-load of d, but the
whole point of this null asm is to avoid this store-load by pretending
that the asm does it) with clang.  If the constraints are changed to
"=&t" and "t", then it works for clang but fails (with constraint
and/or reload errors) with gcc.


More information about the freebsd-numerics mailing list