https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124337
Bug ID: 124337
Summary: assemble failure of movdir64b with -masm=intel
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: assemble-failure
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 63809
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=63809&action=edit
reduced testcase
Output:
$ x86_64-pc-linux-gnu-gcc -mmovdir64b testcase.c -masm=intel
/tmp/cceUd5tt.s: Assembler messages:
/tmp/cceUd5tt.s:22: Error: operand size mismatch for `movdir64b'
The instruction:
movdir64b rax, ZMMWORD PTR [rdx]
has the (very correctly looking) "ZMMWORD PTR" that is however intentionally
implicit, see https://sourceware.org/pipermail/binutils/2018-May/102813.html
> Almost all the same here. Additionally, while I can see that ZMMword fits
> the 64-byte operand size, I really think it would look rather odd to have
> "zmmword ptr" used on an operand here. Simply require no operand size
> prefix (in Intel syntax mode), just like you make the disassembler not
> produce any?
I don't know if this is a gcc bug (since the asm is rejected), or binutils
should allow both forms (ZMMWORD PTR really matches the operand size).
I think there are a few other similar issues with extraneous xMMWORD PTR.
This is failing with binutils HEAD as of now:
$ as -v
GNU assembler version 2.46.50 (x86_64-pc-linux-gnu) using BFD version (Gentoo
9999 p1) 2.46.50.20260302
