[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: hjl.tools at gmail dot com
Subject: [Bug gas/18638] Wrong code generated for VMOVQ and VGATHER... on x86 CPU
Date: Thu, 09 Jul 2015 19:20:03 +0000


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]