#include <stdint.h> uint64_t extract_double (double x) { union { double dbl; uint64_t u; } t; t.dbl = x; return t.u; } Compile this function with "x86_64-pc-linux-gnu-gcc -O2 -march=core2 -S a.c", and we get the following assembly codes: extract_double: .LFB0: .cfi_startproc movd %xmm0, %rax ret The instruction "movd %xmm0, %rax" is nonstandard. Movd should be replaced by movq. (GNU assembler silently accepts it as if it were "movq %xmm0, %rax", so it probably has caused no practical problems.)
Indeed. Following patch fixes the problem: Index: i386.md =================================================================== --- i386.md (revision 157132) +++ i386.md (working copy) @@ -3245,7 +3245,7 @@ case 9: case 10: - return "%vmovd\t{%1, %0|%0, %1}"; + return "%vmovq\t{%1, %0|%0, %1}"; default: gcc_unreachable();
This is done on purpose to provide backward compatibility since vmovq isn't in original x86-64 spec and older assemblers don't support it. From i386-opc.tbl in binutils: // These really shouldn't allow for Reg64 (movq is the right mnemonic for // copying between Reg64/Mem64 and RegXMM/RegMMX, as is mandated by Intel's // spec). AMD's spec, having been in existence for much longer, failed to // recognize that and specified movd for 32- and 64-bit operations. // vmovd really shouldn't allow for 64bit operand (vmovq is the right // mnemonic for copying between Reg64/Mem64 and RegXMM, as is mandated // by Intel AVX spec). To avoid extra template in gcc x86 backend and // support assembler for AMD64, we accept 64bit operand on vmovd so // that we can use one template for both SSE and AVX instructions.
I fail to see why binutils accepting both version should be a reason to not fix gcc.
(In reply to comment #3) > I fail to see why binutils accepting both version should be a reason to > not fix gcc. > What is the minimum binutils required by gcc? Does it support movq?
(In reply to comment #4) > What is the minimum binutils required by gcc? Does it support movq? install.texi says that i?86-linux-gnu requires 2.13.1. Since you are listed as x86 binutils maintainer, I would expect that you can provide the information if it includes correct movq support.
(In reply to comment #5) > install.texi says that i?86-linux-gnu requires 2.13.1. binutils-2.13.1.tar.bz2 07-Nov-2002 23:45 9.5M binutils-2.13.1.tar.gz 07-Nov-2002 23:45 12M IMNSHO, I really can't see the reason why we should support *eight* years old toolchain part with a new compiler. Does it even build with gcc-4.5?
(In reply to comment #5) > (In reply to comment #4) > > > What is the minimum binutils required by gcc? Does it support movq? > > install.texi says that i?86-linux-gnu requires 2.13.1. > > Since you are listed as x86 binutils maintainer, I would expect that you can > provide the information if it includes correct movq support. "movq" was added by http://sourceware.org/ml/binutils/2005-07/msg00134.html in binutils-2.17.
(In reply to comment #6) > (In reply to comment #5) > > > install.texi says that i?86-linux-gnu requires 2.13.1. > > binutils-2.13.1.tar.bz2 07-Nov-2002 23:45 9.5M > binutils-2.13.1.tar.gz 07-Nov-2002 23:45 12M > > IMNSHO, I really can't see the reason why we should support *eight* years old > toolchain part with a new compiler. Does it even build with gcc-4.5? > It may be a good idea by itself. However, since AMD64 uses movd instead of movq, some non-GNU assemblers may not support movq. Why change it when nothing is broken?
(In reply to comment #8) > It may be a good idea by itself. However, since AMD64 uses movd instead > of movq, some non-GNU assemblers may not support movq. Why change it > when nothing is broken? Indeed.