[Bug gas/18638] Wrong code generated for VMOVQ and VGATHER... on x86 CPU

[hjl.tools at gmail dot com]

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

address@hidden tmp]$ gcc -c a.s    
address@hidden 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
address@hidden 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.