Comment author: @xavierleroy

I cannot reproduce the problem on my Mandriva x86_64 installation.
The two "movabs" instructions generated are:
movabsq $9223372036854775807, %rcx
movabsq $9223372036854775807, %rax
as --version says
GNU assembler 2.15.90.0.3 20040415

Could you please compile the following C snippet on your machine
using "gcc -S" and look at the generated .s file? On my machine,
it generates a "movabsq" instruction.

long f(void)
{
return 9223372036854775807;
}

Comment author: @xavierleroy

[ I'm not sure you were notified of the first note, so here is a copy. ]

I cannot reproduce the problem on my Mandriva x86_64 installation.
The two "movabs" instructions generated are:
movabsq $9223372036854775807, %rcx
movabsq $9223372036854775807, %rax
as --version says
GNU assembler 2.15.90.0.3 20040415

Could you please compile the following C snippet on your machine
using "gcc -S" and look at the generated .s file? On my machine,
it generates a "movabsq" instruction.

long f(void)
{
return 9223372036854775807;
}

Comment author: NicolasArchambault

For me, the two movabs instructions are (Sarge and Sid) :
movabsq $9223372036854775807, 32(%rsp)
movabsq $9223372036854775807, %rax

Your snippet generates the same instruction :
movabsq $9223372036854775807, %rax

Sarge :
as --version
GNU assembler 2.15

Sid :
as --version
GNU assembler 2.17 Debian GNU/Linux

Sorry, I had your note yesterday but was unable to test at the moment.

Comment author: @xavierleroy

The culprit is movabsq $xxxxx, 32($rsp), which is incorrect indeed.
Fixed in 3.09.3, file asmcomp/amd64/reload.ml