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: [hjl@gnu-6 tmp]$ cat i.s orq $-0x100, %rax orq $0xffffffffFFFFFF00, %rax [hjl@gnu-6 tmp]$ gcc -c i.s [hjl@gnu-6 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 [hjl@gnu-6 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. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
