[Top][All Lists]

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

[Bug gas/18723] New: gas will not assemble EVEX coded instructions witho

From: m at rolle dot name
Subject: [Bug gas/18723] New: gas will not assemble EVEX coded instructions without zmm registers
Date: Mon, 27 Jul 2015 02:04:53 +0000


            Bug ID: 18723
           Summary: gas will not assemble EVEX coded instructions without
                    zmm registers
           Product: binutils
           Version: 2.24
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gas
          Assignee: unassigned at sourceware dot org
          Reporter: m at rolle dot name
  Target Milestone: ---

gas complains about "invalid register operand" for an instruction using ymm16
.. ymm31, or same for xmm.  Likewise if it uses ymm0 -- ymm15 and an EVEX

I believe the source of this problem is that the templates file,
opcodes/i386-opc.tbl, only has templates for ZMM operands.  At least in some
cases, so I presume this applies across the board.  For example, vaddps has
these entries in the EVEX section:

vaddps, 3, 0x58, None, 1, CpuAVX512F,
RegZMM, RegZMM }
vaddps, 4, 0x58, None, 1, CpuAVX512F,
{ Imm8, RegZMM, RegZMM, RegZMM }

I may have an out-of-date source, since I got it from the Cygwin package
manager.  I know some files are out of date because they have bugs which have
since been fixed and are fixed in the binutils binary package from Cygwin.  The
`as` binary does, in fact, make these complaints, and it is version 2.24:

GNU assembler version 2.24.51 (x86_64-pc-cygwin) using BFD version (GNU

I don't consider this a critical bug because it does not produce incorrect
code.  However, by not accepting all of these valid instructions, it can be
unusable for some programs.

By the way, objdump disassembly also gets things wrong with instructions that I
have to assemble with .byte.  It gives me the right operand types, but if I
have a broadcast decorator, it shows {1to8} or {1to16} as though the
destination is 512 bits, regardless of the actual.  I'll file a separate bug
for this.

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]