https://sourceware.org/bugzilla/show_bug.cgi?id=18638
H.J. Lu <hjl.tools at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |WAITING
CC| |hjl.tools at gmail dot com
--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Michael Rolle from comment #0)
> Two issues here, both with the binary code generated by gas. These are seen
> in the testsuite files.
>
> (1) vmovq rcx, xmm4
>
> Generates C4 E1 FD 7E E1.
> The VEX.L bit (the 8's bit of the third byte) is 1. However, AMD spec says
> you
> must have VEX.L = 0, and in fact, VEX.L = 1 causes a #UD exception.
> Intel document says the same thing.
With binutils master branch, I got
[hjl@gnu-6 tmp]$ gcc -c a.s
[hjl@gnu-6 tmp]$ objdump -dw a.o
a.o: file format elf64-x86-64
Disassembly of section .text:
0000000000000000 <.text>:
0: c4 e1 f9 7e e1 vmovq %xmm4,%rcx
[hjl@gnu-6 tmp]$
It is F9, not FD.
> (2) vgather...
>
> Generates a ModR/M byte with the r/m field = 000b. However, Intel spec says
> a #UD will "cause a #UD if the memory operand is encoded without the SIB
> byte". I interpret this to mean that the r/m field must be 100b. AMD spec
> says specifically that there is a #UD if "MODRM.rm != 100b".
Do you have a testcase?
--
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
