bug-binutils
[Top][All Lists]
Advanced

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

[Bug binutils/18736] New: x86 vcvtsi2sd has {er} decorator in wrong plac


From: m at rolle dot name
Subject: [Bug binutils/18736] New: x86 vcvtsi2sd has {er} decorator in wrong place
Date: Wed, 29 Jul 2015 19:22:33 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=18736

            Bug ID: 18736
           Summary: x86 vcvtsi2sd has {er} decorator in wrong place
           Product: binutils
           Version: 2.24
            Status: NEW
          Severity: normal
          Priority: P2
         Component: binutils
          Assignee: unassigned at sourceware dot org
          Reporter: m at rolle dot name
  Target Milestone: ---

The vcvtsi2sd instruction has the {er} decorator associated with the last
operand.  See Intel doc:

EVEX.NDS.LIG.F2.0F.W1 2A /r
VCVTSI2SD xmm1, xmm2, r/m64{er}

However, objdump produces, as an example,

    5290:       62 61 97 10 2a f0       vcvtsi2sd xmm30,xmm29,{rn-sae},rax

Also, as requires the form

vcvtsi2sd xmm30,xmm29,{rn-sae},rax

and it will not accept the (proper) form

vcvtsi2sd xmm30,xmm29,rax,{rn-sae}        #  Error: operand type mismatch for
`vcvtsi2sd'

as does not produce incorrect code, but it is a serious problem because it will
not assemble code that follows the Intel spec.

I suspect that in both as and objdump, there is logic that associates the {er}
decorator with the last _vector_ source operand, rather than the last vector or
GPR source.  They correctly ignore immediate operands.

-- 
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]