[Bug binutils/14129] andq and orq instructions give 'invalid operand' error when MSB of 32-bit immediate is set

[hjl.tools at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14129

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> 2012-05-25 16:35:17 
UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > orq and andq take a signed 32-bit value from -0x80000000 to
> > 0x7ffffffff.  0xFFFFFF00 is out of range.
> 
> (Is 0x7ffffffff a typo for 0x7fffffff?)

Yes, it is a typo.

> 
> Ref: http://download.intel.com/products/processor/manual/325462.pdf
> 
> chapter 3.2, 'and' instruction description:
> 
> "RAX AND imm32 signextended to 64-bits."
> 
> Ditto for OR.
> 
> andq and orq take 32-bit immediate values (and sign extend them to 
> 64-bit)which
> implies that the valid range is 0x0 to 0xFFFFFFFF. I fail to understand how
> 0xFFFFFF00 is out-of-range.
> 
> Although not a standard reference, I would also like to cite that microsoft
> assembler does assemble the above instruction without error.
> 
> I think the bug is valid.

That is a bug in Microsoft assembler:

address@hidden tmp]$ cat i.s
    orq $-0x100, %rax
    orq $0xffffffffFFFFFF00, %rax
address@hidden tmp]$ gcc -c i.s
address@hidden tmp]$ objdump -dw i.o

i.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <.text>:
   0:    48 0d 00 ff ff ff        or     $0xffffffffffffff00,%rax
   6:    48 0d 00 ff ff ff        or     $0xffffffffffffff00,%rax
address@hidden tmp]$ 


As you can see, it takes a signed 32-bit immediate, not unsigned.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.