* [PATCH v8 0/2] x86: replace adhoc (partly wrong) ambiguous operand checking for MOVSX/MOVZX
@ 2020-02-14 12:21 Jan Beulich
2020-02-14 12:26 ` [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous " Jan Beulich
2020-02-14 12:26 ` [PATCH v8 1/2] x86: replace adhoc (partly wrong) ambiguous operand checking " Jan Beulich
0 siblings, 2 replies; 27+ messages in thread
From: Jan Beulich @ 2020-02-14 12:21 UTC (permalink / raw)
To: binutils; +Cc: H.J. Lu
1: x86: replace adhoc (partly wrong) ambiguous operand checking for MOVSX/MOVZX
2: x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
v8 is just to split out the controversial part, in the hope
that at least the main change can go in.
Jan
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
2020-02-14 12:21 [PATCH v8 0/2] x86: replace adhoc (partly wrong) ambiguous operand checking for MOVSX/MOVZX Jan Beulich
@ 2020-02-14 12:26 ` Jan Beulich
2020-02-14 12:28 ` H.J. Lu
2020-02-14 12:26 ` [PATCH v8 1/2] x86: replace adhoc (partly wrong) ambiguous operand checking " Jan Beulich
1 sibling, 1 reply; 27+ messages in thread
From: Jan Beulich @ 2020-02-14 12:26 UTC (permalink / raw)
To: binutils; +Cc: H.J. Lu
As pointed out in "x86: replace adhoc (partly wrong) ambiguous operand
checking for MOVSX/MOVZX" silently guessing what the programmer may have
meant is not helpful, the more that we don't do so elsewhere anymore
(except in cases where it is overwhelmingly likely that the other case
isn't meant, like here for it meant to be a "sign/zero extension" from
16 bits to 16 bits).
gas/
2020-02-XX Jan Beulich <jbeulich@suse.com>
PR gas/25438
* config/tc-i386.c (process_suffix): Default movsx/movzx to byte
suffix only when destination is a word reg.
testsuite/gas/i386/noreg16.l, testsuite/gas/i386/noreg32.l,
testsuite/gas/i386/noreg64.l: Adjust expectations.
---
v8: New, split from previous patch.
--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -6335,10 +6335,11 @@ process_suffix (void)
break;
}
- /* As an exception, movsx/movzx silently default to a byte source
- in AT&T mode. */
+ /* As an exception, movsx/movzx with a word register destination
+ silently default to a byte source in AT&T mode, as their word
+ memory source case isn't really useful. */
if ((i.tm.base_opcode | 8) == 0xfbe && i.tm.opcode_modifier.w
- && !i.suffix && !intel_syntax)
+ && !i.suffix && !intel_syntax && i.types[1].bitfield.word)
i.suffix = BYTE_MNEM_SUFFIX;
}
else if (i.suffix == BYTE_MNEM_SUFFIX)
--- a/gas/testsuite/gas/i386/noreg16.l
+++ b/gas/testsuite/gas/i386/noreg16.l
@@ -56,6 +56,8 @@
.*:[1-9][0-9]*: Warning: .* `mov'
.*:[1-9][0-9]*: Warning: .* `movs'
.*:[1-9][0-9]*: Warning: .* `movs'
+.*:[1-9][0-9]*: Warning: .* `movsx'
+.*:[1-9][0-9]*: Warning: .* `movzx'
.*:[1-9][0-9]*: Warning: .* `mul'
.*:[1-9][0-9]*: Warning: .* `neg'
.*:[1-9][0-9]*: Warning: .* `nop'
--- a/gas/testsuite/gas/i386/noreg32.l
+++ b/gas/testsuite/gas/i386/noreg32.l
@@ -61,6 +61,8 @@
.*:[1-9][0-9]*: Warning: .* `mov'
.*:[1-9][0-9]*: Warning: .* `movs'
.*:[1-9][0-9]*: Warning: .* `movs'
+.*:[1-9][0-9]*: Warning: .* `movsx'
+.*:[1-9][0-9]*: Warning: .* `movzx'
.*:[1-9][0-9]*: Warning: .* `mul'
.*:[1-9][0-9]*: Warning: .* `neg'
.*:[1-9][0-9]*: Warning: .* `nop'
--- a/gas/testsuite/gas/i386/noreg64.l
+++ b/gas/testsuite/gas/i386/noreg64.l
@@ -67,6 +67,10 @@
.*:[1-9][0-9]*: Warning: .* `mov'
.*:[1-9][0-9]*: Warning: .* `movs'
.*:[1-9][0-9]*: Warning: .* `movs'
+.*:[1-9][0-9]*: Warning: .* `movsx'
+.*:[1-9][0-9]*: Warning: .* `movsx'
+.*:[1-9][0-9]*: Warning: .* `movzx'
+.*:[1-9][0-9]*: Warning: .* `movzx'
.*:[1-9][0-9]*: Warning: .* `mul'
.*:[1-9][0-9]*: Warning: .* `neg'
.*:[1-9][0-9]*: Warning: .* `nop'
^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH v8 1/2] x86: replace adhoc (partly wrong) ambiguous operand checking for MOVSX/MOVZX
2020-02-14 12:21 [PATCH v8 0/2] x86: replace adhoc (partly wrong) ambiguous operand checking for MOVSX/MOVZX Jan Beulich
2020-02-14 12:26 ` [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous " Jan Beulich
@ 2020-02-14 12:26 ` Jan Beulich
2020-02-14 12:31 ` H.J. Lu
2020-02-14 12:34 ` H.J. Lu
1 sibling, 2 replies; 27+ messages in thread
From: Jan Beulich @ 2020-02-14 12:26 UTC (permalink / raw)
To: binutils; +Cc: H.J. Lu
For these to get treatment consistent with other operand size checking
the special logic shouldn't live in md_assemble(), but process_suffix().
And there's more logic involved than simply zapping the suffix.
Note however that MOVS[BW]* and MOVZ[BW]* still won't be fully
consistent, due to the objection to fold MOVS* templates just like was
done for MOVZ* in c07315e0c6 ("x86: allow suffix-less movzw and 64-bit
movzb").
Note further that it is against my own intentions to have MOVSX/MOVZX
silently default to a byte source in AT&T mode. This should happen only
when the desination register is a 16-bit one. In all other cases there
is an ambiguity, and the user should be warned. But it was explicitly
requested for this to be done in a way inconsistent with everything
else.
Note finally that the assembler change points out (and this patch fixes)
a wrong Intel syntax test introduced by bc31405ebb2c ("x86-64: Properly
encode and decode movsxd"): When source code specifies a 16-bit
destination register, disassembly expectations shouldn't have been to
find a 32-bit one.
gas/
2020-02-XX Jan Beulich <jbeulich@suse.com>
PR gas/25438
* config/tc-i386.c (md_assemble): Move movsx/movzx special
casing ...
(process_suffix): ... here. Consider just the first operand
initially.
(check_long_reg): Drop opcode 0x63 special case again.
* testsuite/gas/i386/i386.s, testsuite/gas/i386/iamcu-1.s,
testsuite/gas/i386/ilp32/x86-64.s, testsuite/gas/i386/x86_64.s:
Move ambiguous operand size tests ...
* testsuite/gas/i386/noreg16.s, testsuite/gas/i386/noreg32.s,
testsuite/gas/i386/noreg64.s: ... here.
* testsuite/gas/i386/i386.d, testsuite/gas/i386/i386-intel.d
testsuite/gas/i386/iamcu-1.d, testsuite/gas/i386/ilp32/x86-64.d,
testsuite/gas/i386/k1om.d, testsuite/gas/i386/l1om.d,
testsuite/gas/i386/movx16.l, testsuite/gas/i386/movx32.l,
testsuite/gas/i386/movx64.l, testsuite/gas/i386/noreg16.d,
testsuite/gas/i386/noreg32.d, testsuite/gas/i386/noreg64.d,
testsuite/gas/i386/x86-64-movsxd.d,
testsuite/gas/i386/x86-64-movsxd-intel.d,
testsuite/gas/i386/x86_64.d, testsuite/gas/i386/x86_64-intel.d:
Adjust expectations.
* testsuite/gas/i386/movx16.s, testsuite/gas/i386/movx16.l,
testsuite/gas/i386/movx32.s, testsuite/gas/i386/movx32.l,
testsuite/gas/i386/movx64.s, testsuite/gas/i386/movx64.l: New.
* testsuite/gas/i386/i386.exp: Run new tests.
opcodes/
2020-02-XX Jan Beulich <jbeulich@suse.com>
PR gas/25438
* i386-opc.tbl (movsx): Fold patterns. Also allow Reg32 as
destination for Cpu64-only variant.
(movsxd): Also allow Reg32 as destination. Drop Rex64.
(movzx): Fold patterns.
* i386-tbl.h: Re-generate.
---
v8: Silently default movsx/movsx to byte source in AT&T mode
irrespective of destination register size.
v7: Merge with previously separate patch introducing new testcases.
v6: Move to end of series.
v5: Re-base.
v4: Re-base.
v3: Re-base.
v2: Undo No_lSuf addition to MOVSXD template. Drop bogus / pointless
!i.tm.opcode_modifier.rex64 part of conditional in md_assemble().
Re-base over changes earlier in the series.
--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -4381,22 +4381,6 @@ md_assemble (char *line)
: as_bad) (_("SSE instruction `%s' is used"), i.tm.name);
}
- /* Zap movzx and movsx suffix. The suffix has been set from
- "word ptr" or "byte ptr" on the source operand in Intel syntax
- or extracted from mnemonic in AT&T syntax. But we'll use
- the destination register to choose the suffix for encoding. */
- if ((i.tm.base_opcode & ~9) == 0x0fb6)
- {
- /* In Intel syntax, there must be a suffix. In AT&T syntax, if
- there is no suffix, the default will be byte extension. */
- if (i.reg_operands != 2
- && !i.suffix
- && intel_syntax)
- as_bad (_("ambiguous operand size for `%s'"), i.tm.name);
-
- i.suffix = 0;
- }
-
if (i.tm.opcode_modifier.fwait)
if (!add_prefix (FWAIT_OPCODE))
return;
@@ -6313,6 +6297,15 @@ process_suffix (void)
else if (i.reg_operands
&& (i.operands > 1 || i.types[0].bitfield.class == Reg))
{
+ unsigned int numop = i.operands;
+
+ /* movsx/movzx want only their source operand considered here, for the
+ ambiguity checking below. The suffix will be replaced afterwards
+ to represent the destination (register). */
+ if (((i.tm.base_opcode | 8) == 0xfbe && i.tm.opcode_modifier.w)
+ || (i.tm.base_opcode == 0x63 && i.tm.cpu_flags.bitfield.cpu64))
+ --i.operands;
+
/* If there's no instruction mnemonic suffix we try to invent one
based on GPR operands. */
if (!i.suffix)
@@ -6341,6 +6334,12 @@ process_suffix (void)
continue;
break;
}
+
+ /* As an exception, movsx/movzx silently default to a byte source
+ in AT&T mode. */
+ if ((i.tm.base_opcode | 8) == 0xfbe && i.tm.opcode_modifier.w
+ && !i.suffix && !intel_syntax)
+ i.suffix = BYTE_MNEM_SUFFIX;
}
else if (i.suffix == BYTE_MNEM_SUFFIX)
{
@@ -6387,6 +6386,9 @@ process_suffix (void)
;
else
abort ();
+
+ /* Undo the movsx/movzx change done above. */
+ i.operands = numop;
}
else if (i.tm.opcode_modifier.defaultsize && !i.suffix)
{
@@ -6540,6 +6542,10 @@ process_suffix (void)
if (i.tm.opcode_modifier.floatmf)
i.suffix = SHORT_MNEM_SUFFIX;
+ else if ((i.tm.base_opcode | 8) == 0xfbe
+ || (i.tm.base_opcode == 0x63
+ && i.tm.cpu_flags.bitfield.cpu64))
+ /* handled below */;
else if (evex)
i.tm.opcode_modifier.evex = evex;
else if (flag_code == CODE_16BIT)
@@ -6551,6 +6557,32 @@ process_suffix (void)
}
}
+ if ((i.tm.base_opcode | 8) == 0xfbe
+ || (i.tm.base_opcode == 0x63 && i.tm.cpu_flags.bitfield.cpu64))
+ {
+ /* In Intel syntax, movsx/movzx must have a "suffix" (checked above).
+ In AT&T syntax, if there is no suffix (warned about above), the default
+ will be byte extension. */
+ if (i.tm.opcode_modifier.w && i.suffix && i.suffix != BYTE_MNEM_SUFFIX)
+ i.tm.base_opcode |= 1;
+
+ /* For further processing, the suffix should represent the destination
+ (register). This is already the case when one was used with
+ mov[sz][bw]*, but we need to replace it for mov[sz]x, or if there was
+ no suffix to begin with. */
+ if (i.tm.opcode_modifier.w || i.tm.base_opcode == 0x63 || !i.suffix)
+ {
+ if (i.types[1].bitfield.word)
+ i.suffix = WORD_MNEM_SUFFIX;
+ else if (i.types[1].bitfield.qword)
+ i.suffix = QWORD_MNEM_SUFFIX;
+ else
+ i.suffix = LONG_MNEM_SUFFIX;
+
+ i.tm.opcode_modifier.w = 0;
+ }
+ }
+
if (!i.tm.opcode_modifier.modrm && i.reg_operands && i.tm.operands < 3)
i.short_form = (i.tm.operand_types[0].bitfield.class == Reg)
!= (i.tm.operand_types[1].bitfield.class == Reg);
@@ -6757,9 +6789,7 @@ check_long_reg (void)
&& i.tm.operand_types[op].bitfield.dword)
{
if (intel_syntax
- && (i.tm.opcode_modifier.toqword
- /* Also convert to QWORD for MOVSXD. */
- || i.tm.base_opcode == 0x63)
+ && i.tm.opcode_modifier.toqword
&& i.types[0].bitfield.class != RegSIMD)
{
/* Convert to QWORD. We want REX byte. */
--- a/gas/testsuite/gas/i386/i386-intel.d
+++ b/gas/testsuite/gas/i386/i386-intel.d
@@ -14,7 +14,6 @@ Disassembly of section .text:
[ ]*[a-f0-9]+: 66 0f be f0 movsx si,al
[ ]*[a-f0-9]+: 0f be f0 movsx esi,al
[ ]*[a-f0-9]+: 0f bf f0 movsx esi,ax
-[ ]*[a-f0-9]+: 0f be 10 movsx edx,BYTE PTR \[eax\]
[ ]*[a-f0-9]+: 66 0f be 10 movsx dx,BYTE PTR \[eax\]
[ ]*[a-f0-9]+: 66 0f be 10 movsx dx,BYTE PTR \[eax\]
[ ]*[a-f0-9]+: 0f be 10 movsx edx,BYTE PTR \[eax\]
@@ -25,7 +24,6 @@ Disassembly of section .text:
[ ]*[a-f0-9]+: 66 0f b6 f0 movzx si,al
[ ]*[a-f0-9]+: 0f b6 f0 movzx esi,al
[ ]*[a-f0-9]+: 0f b7 f0 movzx esi,ax
-[ ]*[a-f0-9]+: 0f b6 10 movzx edx,BYTE PTR \[eax\]
[ ]*[a-f0-9]+: 66 0f b6 10 movzx dx,BYTE PTR \[eax\]
[ ]*[a-f0-9]+: 66 0f b6 10 movzx dx,BYTE PTR \[eax\]
[ ]*[a-f0-9]+: 0f b6 10 movzx edx,BYTE PTR \[eax\]
--- a/gas/testsuite/gas/i386/i386.d
+++ b/gas/testsuite/gas/i386/i386.d
@@ -13,7 +13,6 @@ Disassembly of section .text:
[ ]*[a-f0-9]+: 66 0f be f0 movsbw %al,%si
[ ]*[a-f0-9]+: 0f be f0 movsbl %al,%esi
[ ]*[a-f0-9]+: 0f bf f0 movswl %ax,%esi
-[ ]*[a-f0-9]+: 0f be 10 movsbl \(%eax\),%edx
[ ]*[a-f0-9]+: 66 0f be 10 movsbw \(%eax\),%dx
[ ]*[a-f0-9]+: 66 0f be 10 movsbw \(%eax\),%dx
[ ]*[a-f0-9]+: 0f be 10 movsbl \(%eax\),%edx
@@ -24,7 +23,6 @@ Disassembly of section .text:
[ ]*[a-f0-9]+: 66 0f b6 f0 movzbw %al,%si
[ ]*[a-f0-9]+: 0f b6 f0 movzbl %al,%esi
[ ]*[a-f0-9]+: 0f b7 f0 movzwl %ax,%esi
-[ ]*[a-f0-9]+: 0f b6 10 movzbl \(%eax\),%edx
[ ]*[a-f0-9]+: 66 0f b6 10 movzbw \(%eax\),%dx
[ ]*[a-f0-9]+: 66 0f b6 10 movzbw \(%eax\),%dx
[ ]*[a-f0-9]+: 0f b6 10 movzbl \(%eax\),%edx
--- a/gas/testsuite/gas/i386/i386.exp
+++ b/gas/testsuite/gas/i386/i386.exp
@@ -132,6 +132,8 @@ if [expr ([istarget "i*86-*-*"] || [ist
run_list_test "noreg16"
run_dump_test "noreg32"
run_list_test "noreg32"
+ run_list_test "movx16" "-I${srcdir}/$subdir -al"
+ run_list_test "movx32" "-al"
run_dump_test "addr16"
run_dump_test "addr32"
run_dump_test "code16"
@@ -734,6 +736,7 @@ if [expr ([istarget "i*86-*-*"] || [ista
run_list_test "x86-64-sysenter-amd" "-mamd64"
run_dump_test "noreg64"
run_list_test "noreg64"
+ run_list_test "movx64" "-al"
run_list_test "cvtsi2sX"
run_dump_test "x86-64-sse4_1"
run_dump_test "x86-64-sse4_1-intel"
--- a/gas/testsuite/gas/i386/i386.s
+++ b/gas/testsuite/gas/i386/i386.s
@@ -9,7 +9,6 @@
movsx %al, %si
movsx %al, %esi
movsx %ax, %esi
- movsx (%eax), %edx
movsx (%eax), %dx
movsxb (%eax), %dx
movsxb (%eax), %edx
@@ -21,7 +20,6 @@
movzx %al, %si
movzx %al, %esi
movzx %ax, %esi
- movzx (%eax), %edx
movzx (%eax), %dx
movzxb (%eax), %dx
movzxb (%eax), %edx
--- a/gas/testsuite/gas/i386/iamcu-1.d
+++ b/gas/testsuite/gas/i386/iamcu-1.d
@@ -10,7 +10,6 @@ Disassembly of section .text:
[ ]*[a-f0-9]+: 66 0f be f0 movsbw %al,%si
[ ]*[a-f0-9]+: 0f be f0 movsbl %al,%esi
[ ]*[a-f0-9]+: 0f bf f0 movswl %ax,%esi
-[ ]*[a-f0-9]+: 0f be 10 movsbl \(%eax\),%edx
[ ]*[a-f0-9]+: 66 0f be 10 movsbw \(%eax\),%dx
[ ]*[a-f0-9]+: 66 0f be 10 movsbw \(%eax\),%dx
[ ]*[a-f0-9]+: 0f be 10 movsbl \(%eax\),%edx
@@ -21,7 +20,6 @@ Disassembly of section .text:
[ ]*[a-f0-9]+: 66 0f b6 f0 movzbw %al,%si
[ ]*[a-f0-9]+: 0f b6 f0 movzbl %al,%esi
[ ]*[a-f0-9]+: 0f b7 f0 movzwl %ax,%esi
-[ ]*[a-f0-9]+: 0f b6 10 movzbl \(%eax\),%edx
[ ]*[a-f0-9]+: 66 0f b6 10 movzbw \(%eax\),%dx
[ ]*[a-f0-9]+: 66 0f b6 10 movzbw \(%eax\),%dx
[ ]*[a-f0-9]+: 0f b6 10 movzbl \(%eax\),%edx
--- a/gas/testsuite/gas/i386/iamcu-1.s
+++ b/gas/testsuite/gas/i386/iamcu-1.s
@@ -4,7 +4,6 @@
movsx %al, %si
movsx %al, %esi
movsx %ax, %esi
- movsx (%eax), %edx
movsx (%eax), %dx
movsxb (%eax), %dx
movsxb (%eax), %edx
@@ -16,7 +15,6 @@
movzx %al, %si
movzx %al, %esi
movzx %ax, %esi
- movzx (%eax), %edx
movzx (%eax), %dx
movzxb (%eax), %dx
movzxb (%eax), %edx
--- a/gas/testsuite/gas/i386/ilp32/x86-64.d
+++ b/gas/testsuite/gas/i386/ilp32/x86-64.d
@@ -162,8 +162,6 @@ Disassembly of section .text:
[ ]*[a-f0-9]+: 0f bf f0 movswl %ax,%esi
[ ]*[a-f0-9]+: 48 0f bf f0 movswq %ax,%rsi
[ ]*[a-f0-9]+: 48 63 f0 movslq %eax,%rsi
-[ ]*[a-f0-9]+: 0f be 10 movsbl \(%rax\),%edx
-[ ]*[a-f0-9]+: 48 0f be 10 movsbq \(%rax\),%rdx
[ ]*[a-f0-9]+: 66 0f be 10 movsbw \(%rax\),%dx
[ ]*[a-f0-9]+: 0f be 10 movsbl \(%rax\),%edx
[ ]*[a-f0-9]+: 48 0f be 10 movsbq \(%rax\),%rdx
@@ -175,8 +173,6 @@ Disassembly of section .text:
[ ]*[a-f0-9]+: 48 0f b6 f0 movzbq %al,%rsi
[ ]*[a-f0-9]+: 0f b7 f0 movzwl %ax,%esi
[ ]*[a-f0-9]+: 48 0f b7 f0 movzwq %ax,%rsi
-[ ]*[a-f0-9]+: 0f b6 10 movzbl \(%rax\),%edx
-[ ]*[a-f0-9]+: 48 0f b6 10 movzbq \(%rax\),%rdx
[ ]*[a-f0-9]+: 66 0f b6 10 movzbw \(%rax\),%dx
[ ]*[a-f0-9]+: 0f b6 10 movzbl \(%rax\),%edx
[ ]*[a-f0-9]+: 48 0f b6 10 movzbq \(%rax\),%rdx
@@ -220,8 +216,6 @@ Disassembly of section .text:
[ ]*[a-f0-9]+: 9b df e0 fstsw %ax
[ ]*[a-f0-9]+: 9b df e0 fstsw %ax
[ ]*[a-f0-9]+: 66 0f be 00 movsbw \(%rax\),%ax
-[ ]*[a-f0-9]+: 0f be 00 movsbl \(%rax\),%eax
-[ ]*[a-f0-9]+: 48 0f be 00 movsbq \(%rax\),%rax
[ ]*[a-f0-9]+: 66 0f be 10 movsbw \(%rax\),%dx
[ ]*[a-f0-9]+: 0f be 10 movsbl \(%rax\),%edx
[ ]*[a-f0-9]+: 48 0f be 10 movsbq \(%rax\),%rdx
@@ -230,8 +224,6 @@ Disassembly of section .text:
[ ]*[a-f0-9]+: 48 63 10 movslq \(%rax\),%rdx
[ ]*[a-f0-9]+: 48 63 00 movslq \(%rax\),%rax
[ ]*[a-f0-9]+: 66 0f b6 00 movzbw \(%rax\),%ax
-[ ]*[a-f0-9]+: 0f b6 00 movzbl \(%rax\),%eax
-[ ]*[a-f0-9]+: 48 0f b6 00 movzbq \(%rax\),%rax
[ ]*[a-f0-9]+: 66 0f b6 10 movzbw \(%rax\),%dx
[ ]*[a-f0-9]+: 0f b6 10 movzbl \(%rax\),%edx
[ ]*[a-f0-9]+: 48 0f b6 10 movzbq \(%rax\),%rdx
--- a/gas/testsuite/gas/i386/ilp32/x86-64.s
+++ b/gas/testsuite/gas/i386/ilp32/x86-64.s
@@ -194,8 +194,6 @@ cmpxchg16b oword ptr [rax]
movsx %ax, %esi
movsx %ax, %rsi
movsx %eax, %rsi
- movsx (%rax), %edx
- movsx (%rax), %rdx
movsx (%rax), %dx
movsbl (%rax), %edx
movsbq (%rax), %rdx
@@ -208,8 +206,6 @@ cmpxchg16b oword ptr [rax]
movzx %al, %rsi
movzx %ax, %esi
movzx %ax, %rsi
- movzx (%rax), %edx
- movzx (%rax), %rdx
movzx (%rax), %dx
movzb (%rax), %edx
movzb (%rax), %rdx
@@ -263,8 +259,6 @@ cmpxchg16b oword ptr [rax]
.att_syntax
movsx (%rax),%ax
-movsx (%rax),%eax
-movsx (%rax),%rax
movsxb (%rax), %dx
movsxb (%rax), %edx
movsxb (%rax), %rdx
@@ -273,8 +267,6 @@ movsxw (%rax), %rdx
movsxl (%rax), %rdx
movsxd (%rax),%rax
movzx (%rax),%ax
-movzx (%rax),%eax
-movzx (%rax),%rax
movzxb (%rax), %dx
movzxb (%rax), %edx
movzxb (%rax), %rdx
--- a/gas/testsuite/gas/i386/k1om.d
+++ b/gas/testsuite/gas/i386/k1om.d
@@ -175,8 +175,6 @@ Disassembly of section .text:
[ ]*[a-f0-9]+: 0f bf f0 movswl %ax,%esi
[ ]*[a-f0-9]+: 48 0f bf f0 movswq %ax,%rsi
[ ]*[a-f0-9]+: 48 63 f0 movslq %eax,%rsi
-[ ]*[a-f0-9]+: 0f be 10 movsbl \(%rax\),%edx
-[ ]*[a-f0-9]+: 48 0f be 10 movsbq \(%rax\),%rdx
[ ]*[a-f0-9]+: 66 0f be 10 movsbw \(%rax\),%dx
[ ]*[a-f0-9]+: 0f be 10 movsbl \(%rax\),%edx
[ ]*[a-f0-9]+: 48 0f be 10 movsbq \(%rax\),%rdx
@@ -188,8 +186,6 @@ Disassembly of section .text:
[ ]*[a-f0-9]+: 48 0f b6 f0 movzbq %al,%rsi
[ ]*[a-f0-9]+: 0f b7 f0 movzwl %ax,%esi
[ ]*[a-f0-9]+: 48 0f b7 f0 movzwq %ax,%rsi
-[ ]*[a-f0-9]+: 0f b6 10 movzbl \(%rax\),%edx
-[ ]*[a-f0-9]+: 48 0f b6 10 movzbq \(%rax\),%rdx
[ ]*[a-f0-9]+: 66 0f b6 10 movzbw \(%rax\),%dx
[ ]*[a-f0-9]+: 0f b6 10 movzbl \(%rax\),%edx
[ ]*[a-f0-9]+: 48 0f b6 10 movzbq \(%rax\),%rdx
@@ -233,8 +229,6 @@ Disassembly of section .text:
[ ]*[a-f0-9]+: 9b df e0 fstsw %ax
[ ]*[a-f0-9]+: 9b df e0 fstsw %ax
[ ]*[a-f0-9]+: 66 0f be 00 movsbw \(%rax\),%ax
-[ ]*[a-f0-9]+: 0f be 00 movsbl \(%rax\),%eax
-[ ]*[a-f0-9]+: 48 0f be 00 movsbq \(%rax\),%rax
[ ]*[a-f0-9]+: 66 0f be 10 movsbw \(%rax\),%dx
[ ]*[a-f0-9]+: 0f be 10 movsbl \(%rax\),%edx
[ ]*[a-f0-9]+: 48 0f be 10 movsbq \(%rax\),%rdx
@@ -243,8 +237,6 @@ Disassembly of section .text:
[ ]*[a-f0-9]+: 48 63 10 movslq \(%rax\),%rdx
[ ]*[a-f0-9]+: 48 63 00 movslq \(%rax\),%rax
[ ]*[a-f0-9]+: 66 0f b6 00 movzbw \(%rax\),%ax
-[ ]*[a-f0-9]+: 0f b6 00 movzbl \(%rax\),%eax
-[ ]*[a-f0-9]+: 48 0f b6 00 movzbq \(%rax\),%rax
[ ]*[a-f0-9]+: 66 0f b6 10 movzbw \(%rax\),%dx
[ ]*[a-f0-9]+: 0f b6 10 movzbl \(%rax\),%edx
[ ]*[a-f0-9]+: 48 0f b6 10 movzbq \(%rax\),%rdx
--- a/gas/testsuite/gas/i386/l1om.d
+++ b/gas/testsuite/gas/i386/l1om.d
@@ -175,8 +175,6 @@ Disassembly of section .text:
[ ]*[a-f0-9]+: 0f bf f0 movswl %ax,%esi
[ ]*[a-f0-9]+: 48 0f bf f0 movswq %ax,%rsi
[ ]*[a-f0-9]+: 48 63 f0 movslq %eax,%rsi
-[ ]*[a-f0-9]+: 0f be 10 movsbl \(%rax\),%edx
-[ ]*[a-f0-9]+: 48 0f be 10 movsbq \(%rax\),%rdx
[ ]*[a-f0-9]+: 66 0f be 10 movsbw \(%rax\),%dx
[ ]*[a-f0-9]+: 0f be 10 movsbl \(%rax\),%edx
[ ]*[a-f0-9]+: 48 0f be 10 movsbq \(%rax\),%rdx
@@ -188,8 +186,6 @@ Disassembly of section .text:
[ ]*[a-f0-9]+: 48 0f b6 f0 movzbq %al,%rsi
[ ]*[a-f0-9]+: 0f b7 f0 movzwl %ax,%esi
[ ]*[a-f0-9]+: 48 0f b7 f0 movzwq %ax,%rsi
-[ ]*[a-f0-9]+: 0f b6 10 movzbl \(%rax\),%edx
-[ ]*[a-f0-9]+: 48 0f b6 10 movzbq \(%rax\),%rdx
[ ]*[a-f0-9]+: 66 0f b6 10 movzbw \(%rax\),%dx
[ ]*[a-f0-9]+: 0f b6 10 movzbl \(%rax\),%edx
[ ]*[a-f0-9]+: 48 0f b6 10 movzbq \(%rax\),%rdx
@@ -233,8 +229,6 @@ Disassembly of section .text:
[ ]*[a-f0-9]+: 9b df e0 fstsw %ax
[ ]*[a-f0-9]+: 9b df e0 fstsw %ax
[ ]*[a-f0-9]+: 66 0f be 00 movsbw \(%rax\),%ax
-[ ]*[a-f0-9]+: 0f be 00 movsbl \(%rax\),%eax
-[ ]*[a-f0-9]+: 48 0f be 00 movsbq \(%rax\),%rax
[ ]*[a-f0-9]+: 66 0f be 10 movsbw \(%rax\),%dx
[ ]*[a-f0-9]+: 0f be 10 movsbl \(%rax\),%edx
[ ]*[a-f0-9]+: 48 0f be 10 movsbq \(%rax\),%rdx
@@ -243,8 +237,6 @@ Disassembly of section .text:
[ ]*[a-f0-9]+: 48 63 10 movslq \(%rax\),%rdx
[ ]*[a-f0-9]+: 48 63 00 movslq \(%rax\),%rax
[ ]*[a-f0-9]+: 66 0f b6 00 movzbw \(%rax\),%ax
-[ ]*[a-f0-9]+: 0f b6 00 movzbl \(%rax\),%eax
-[ ]*[a-f0-9]+: 48 0f b6 00 movzbq \(%rax\),%rax
[ ]*[a-f0-9]+: 66 0f b6 10 movzbw \(%rax\),%dx
[ ]*[a-f0-9]+: 0f b6 10 movzbl \(%rax\),%edx
[ ]*[a-f0-9]+: 48 0f b6 10 movzbq \(%rax\),%rdx
--- /dev/null
+++ b/gas/testsuite/gas/i386/movx16.l
@@ -0,0 +1,197 @@
+.*: Assembler messages:
+#...
+[ ]*[1-9][0-9]*[ ]+movsx:
+[ ]*[1-9][0-9]*[ ]+movsx %al, %cl
+[ ]*[1-9][0-9]*[ ]+movsx %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movsx %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 0FBEC8[ ]+movsx %al, %cx
+[ ]*[1-9][0-9]* \?\?\?\? 0FBFC8[ ]+movsx %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movsx %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 660FBEC8[ ]+movsx %al, %ecx
+[ ]*[1-9][0-9]* \?\?\?\? 660FBFC8[ ]+movsx %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsx %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsxb %al, %cl
+[ ]*[1-9][0-9]*[ ]+movsxb %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movsxb %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 0FBEC8[ ]+movsxb %al, %cx
+[ ]*[1-9][0-9]*[ ]+movsxb %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movsxb %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 660FBEC8[ ]+movsxb %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movsxb %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsxb %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsxw %al, %cl
+[ ]*[1-9][0-9]*[ ]+movsxw %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movsxw %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsxw %al, %cx
+[ ]*[1-9][0-9]* \?\?\?\? 0FBFC8[ ]+movsxw %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movsxw %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsxw %al, %ecx
+[ ]*[1-9][0-9]* \?\?\?\? 660FBFC8[ ]+movsxw %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsxw %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsb %al, %cl
+[ ]*[1-9][0-9]*[ ]+movsb %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movsb %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsb %al, %cx
+[ ]*[1-9][0-9]*[ ]+movsb %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movsb %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsb %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movsb %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsb %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsbw %al, %cl
+[ ]*[1-9][0-9]*[ ]+movsbw %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movsbw %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 0FBEC8[ ]+movsbw %al, %cx
+[ ]*[1-9][0-9]*[ ]+movsbw %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movsbw %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsbw %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movsbw %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsbw %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsbl %al, %cl
+[ ]*[1-9][0-9]*[ ]+movsbl %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movsbl %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsbl %al, %cx
+[ ]*[1-9][0-9]*[ ]+movsbl %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movsbl %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 660FBEC8[ ]+movsbl %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movsbl %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsbl %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsw %al, %cl
+[ ]*[1-9][0-9]*[ ]+movsw %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movsw %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsw %al, %cx
+[ ]*[1-9][0-9]*[ ]+movsw %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movsw %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsw %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movsw %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsw %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movswl %al, %cl
+[ ]*[1-9][0-9]*[ ]+movswl %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movswl %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movswl %al, %cx
+[ ]*[1-9][0-9]*[ ]+movswl %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movswl %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movswl %al, %ecx
+[ ]*[1-9][0-9]* \?\?\?\? 660FBFC8[ ]+movswl %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movswl %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzx:
+[ ]*[1-9][0-9]*[ ]+movzx %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzx %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzx %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 0FB6C8[ ]+movzx %al, %cx
+[ ]*[1-9][0-9]* \?\?\?\? 0FB7C8[ ]+movzx %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzx %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 660FB6C8[ ]+movzx %al, %ecx
+[ ]*[1-9][0-9]* \?\?\?\? 660FB7C8[ ]+movzx %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzx %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzxb %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzxb %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzxb %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 0FB6C8[ ]+movzxb %al, %cx
+[ ]*[1-9][0-9]*[ ]+movzxb %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzxb %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 660FB6C8[ ]+movzxb %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movzxb %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzxb %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzxw %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzxw %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzxw %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzxw %al, %cx
+[ ]*[1-9][0-9]* \?\?\?\? 0FB7C8[ ]+movzxw %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzxw %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzxw %al, %ecx
+[ ]*[1-9][0-9]* \?\?\?\? 660FB7C8[ ]+movzxw %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzxw %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzb %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzb %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzb %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 0FB6C8[ ]+movzb %al, %cx
+[ ]*[1-9][0-9]*[ ]+movzb %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzb %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 660FB6C8[ ]+movzb %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movzb %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzb %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzbw %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzbw %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzbw %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 0FB6C8[ ]+movzbw %al, %cx
+[ ]*[1-9][0-9]*[ ]+movzbw %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzbw %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzbw %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movzbw %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzbw %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzbl %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzbl %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzbl %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzbl %al, %cx
+[ ]*[1-9][0-9]*[ ]+movzbl %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzbl %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 660FB6C8[ ]+movzbl %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movzbl %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzbl %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzw %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzw %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzw %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzw %al, %cx
+[ ]*[1-9][0-9]*[ ]+movzw %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzw %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzw %al, %ecx
+[ ]*[1-9][0-9]* \?\?\?\? 660FB7C8[ ]+movzw %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzw %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzwl %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzwl %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzwl %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzwl %al, %cx
+[ ]*[1-9][0-9]*[ ]+movzwl %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzwl %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzwl %al, %ecx
+[ ]*[1-9][0-9]* \?\?\?\? 660FB7C8[ ]+movzwl %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzwl %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+#pass
--- /dev/null
+++ b/gas/testsuite/gas/i386/movx16.s
@@ -0,0 +1,2 @@
+ .code16
+ .include "movx32.s"
--- /dev/null
+++ b/gas/testsuite/gas/i386/movx32.l
@@ -0,0 +1,197 @@
+.*: Assembler messages:
+#...
+[ ]*[1-9][0-9]*[ ]+movsx:
+[ ]*[1-9][0-9]*[ ]+movsx %al, %cl
+[ ]*[1-9][0-9]*[ ]+movsx %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movsx %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 660FBEC8[ ]+movsx %al, %cx
+[ ]*[1-9][0-9]* \?\?\?\? 660FBFC8[ ]+movsx %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movsx %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 0FBEC8[ ]+movsx %al, %ecx
+[ ]*[1-9][0-9]* \?\?\?\? 0FBFC8[ ]+movsx %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsx %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsxb %al, %cl
+[ ]*[1-9][0-9]*[ ]+movsxb %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movsxb %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 660FBEC8[ ]+movsxb %al, %cx
+[ ]*[1-9][0-9]*[ ]+movsxb %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movsxb %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 0FBEC8[ ]+movsxb %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movsxb %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsxb %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsxw %al, %cl
+[ ]*[1-9][0-9]*[ ]+movsxw %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movsxw %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsxw %al, %cx
+[ ]*[1-9][0-9]* \?\?\?\? 660FBFC8[ ]+movsxw %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movsxw %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsxw %al, %ecx
+[ ]*[1-9][0-9]* \?\?\?\? 0FBFC8[ ]+movsxw %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsxw %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsb %al, %cl
+[ ]*[1-9][0-9]*[ ]+movsb %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movsb %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsb %al, %cx
+[ ]*[1-9][0-9]*[ ]+movsb %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movsb %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsb %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movsb %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsb %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsbw %al, %cl
+[ ]*[1-9][0-9]*[ ]+movsbw %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movsbw %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 660FBEC8[ ]+movsbw %al, %cx
+[ ]*[1-9][0-9]*[ ]+movsbw %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movsbw %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsbw %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movsbw %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsbw %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsbl %al, %cl
+[ ]*[1-9][0-9]*[ ]+movsbl %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movsbl %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsbl %al, %cx
+[ ]*[1-9][0-9]*[ ]+movsbl %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movsbl %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 0FBEC8[ ]+movsbl %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movsbl %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsbl %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsw %al, %cl
+[ ]*[1-9][0-9]*[ ]+movsw %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movsw %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsw %al, %cx
+[ ]*[1-9][0-9]*[ ]+movsw %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movsw %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsw %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movsw %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsw %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movswl %al, %cl
+[ ]*[1-9][0-9]*[ ]+movswl %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movswl %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movswl %al, %cx
+[ ]*[1-9][0-9]*[ ]+movswl %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movswl %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movswl %al, %ecx
+[ ]*[1-9][0-9]* \?\?\?\? 0FBFC8[ ]+movswl %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movswl %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzx:
+[ ]*[1-9][0-9]*[ ]+movzx %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzx %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzx %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 660FB6C8[ ]+movzx %al, %cx
+[ ]*[1-9][0-9]* \?\?\?\? 660FB7C8[ ]+movzx %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzx %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 0FB6C8[ ]+movzx %al, %ecx
+[ ]*[1-9][0-9]* \?\?\?\? 0FB7C8[ ]+movzx %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzx %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzxb %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzxb %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzxb %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 660FB6C8[ ]+movzxb %al, %cx
+[ ]*[1-9][0-9]*[ ]+movzxb %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzxb %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 0FB6C8[ ]+movzxb %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movzxb %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzxb %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzxw %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzxw %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzxw %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzxw %al, %cx
+[ ]*[1-9][0-9]* \?\?\?\? 660FB7C8[ ]+movzxw %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzxw %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzxw %al, %ecx
+[ ]*[1-9][0-9]* \?\?\?\? 0FB7C8[ ]+movzxw %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzxw %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzb %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzb %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzb %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 660FB6C8[ ]+movzb %al, %cx
+[ ]*[1-9][0-9]*[ ]+movzb %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzb %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 0FB6C8[ ]+movzb %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movzb %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzb %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzbw %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzbw %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzbw %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 660FB6C8[ ]+movzbw %al, %cx
+[ ]*[1-9][0-9]*[ ]+movzbw %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzbw %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzbw %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movzbw %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzbw %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzbl %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzbl %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzbl %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzbl %al, %cx
+[ ]*[1-9][0-9]*[ ]+movzbl %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzbl %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 0FB6C8[ ]+movzbl %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movzbl %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzbl %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzw %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzw %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzw %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzw %al, %cx
+[ ]*[1-9][0-9]*[ ]+movzw %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzw %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzw %al, %ecx
+[ ]*[1-9][0-9]* \?\?\?\? 0FB7C8[ ]+movzw %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzw %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzwl %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzwl %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzwl %eax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzwl %al, %cx
+[ ]*[1-9][0-9]*[ ]+movzwl %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzwl %eax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzwl %al, %ecx
+[ ]*[1-9][0-9]* \?\?\?\? 0FB7C8[ ]+movzwl %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzwl %eax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+#pass
--- /dev/null
+++ b/gas/testsuite/gas/i386/movx32.s
@@ -0,0 +1,197 @@
+ .text
+ .psize 0
+movsx:
+ movsx %al, %cl
+ movsx %ax, %cl
+ movsx %eax, %cl
+
+ movsx %al, %cx
+ movsx %ax, %cx
+ movsx %eax, %cx
+
+ movsx %al, %ecx
+ movsx %ax, %ecx
+ movsx %eax, %ecx
+
+ movsxb %al, %cl
+ movsxb %ax, %cl
+ movsxb %eax, %cl
+
+ movsxb %al, %cx
+ movsxb %ax, %cx
+ movsxb %eax, %cx
+
+ movsxb %al, %ecx
+ movsxb %ax, %ecx
+ movsxb %eax, %ecx
+
+ movsxw %al, %cl
+ movsxw %ax, %cl
+ movsxw %eax, %cl
+
+ movsxw %al, %cx
+ movsxw %ax, %cx
+ movsxw %eax, %cx
+
+ movsxw %al, %ecx
+ movsxw %ax, %ecx
+ movsxw %eax, %ecx
+
+ movsb %al, %cl
+ movsb %ax, %cl
+ movsb %eax, %cl
+
+ movsb %al, %cx
+ movsb %ax, %cx
+ movsb %eax, %cx
+
+ movsb %al, %ecx
+ movsb %ax, %ecx
+ movsb %eax, %ecx
+
+ movsbw %al, %cl
+ movsbw %ax, %cl
+ movsbw %eax, %cl
+
+ movsbw %al, %cx
+ movsbw %ax, %cx
+ movsbw %eax, %cx
+
+ movsbw %al, %ecx
+ movsbw %ax, %ecx
+ movsbw %eax, %ecx
+
+ movsbl %al, %cl
+ movsbl %ax, %cl
+ movsbl %eax, %cl
+
+ movsbl %al, %cx
+ movsbl %ax, %cx
+ movsbl %eax, %cx
+
+ movsbl %al, %ecx
+ movsbl %ax, %ecx
+ movsbl %eax, %ecx
+
+ movsw %al, %cl
+ movsw %ax, %cl
+ movsw %eax, %cl
+
+ movsw %al, %cx
+ movsw %ax, %cx
+ movsw %eax, %cx
+
+ movsw %al, %ecx
+ movsw %ax, %ecx
+ movsw %eax, %ecx
+
+ movswl %al, %cl
+ movswl %ax, %cl
+ movswl %eax, %cl
+
+ movswl %al, %cx
+ movswl %ax, %cx
+ movswl %eax, %cx
+
+ movswl %al, %ecx
+ movswl %ax, %ecx
+ movswl %eax, %ecx
+
+movzx:
+ movzx %al, %cl
+ movzx %ax, %cl
+ movzx %eax, %cl
+
+ movzx %al, %cx
+ movzx %ax, %cx
+ movzx %eax, %cx
+
+ movzx %al, %ecx
+ movzx %ax, %ecx
+ movzx %eax, %ecx
+
+ movzxb %al, %cl
+ movzxb %ax, %cl
+ movzxb %eax, %cl
+
+ movzxb %al, %cx
+ movzxb %ax, %cx
+ movzxb %eax, %cx
+
+ movzxb %al, %ecx
+ movzxb %ax, %ecx
+ movzxb %eax, %ecx
+
+ movzxw %al, %cl
+ movzxw %ax, %cl
+ movzxw %eax, %cl
+
+ movzxw %al, %cx
+ movzxw %ax, %cx
+ movzxw %eax, %cx
+
+ movzxw %al, %ecx
+ movzxw %ax, %ecx
+ movzxw %eax, %ecx
+
+ movzb %al, %cl
+ movzb %ax, %cl
+ movzb %eax, %cl
+
+ movzb %al, %cx
+ movzb %ax, %cx
+ movzb %eax, %cx
+
+ movzb %al, %ecx
+ movzb %ax, %ecx
+ movzb %eax, %ecx
+
+ movzbw %al, %cl
+ movzbw %ax, %cl
+ movzbw %eax, %cl
+
+ movzbw %al, %cx
+ movzbw %ax, %cx
+ movzbw %eax, %cx
+
+ movzbw %al, %ecx
+ movzbw %ax, %ecx
+ movzbw %eax, %ecx
+
+ movzbl %al, %cl
+ movzbl %ax, %cl
+ movzbl %eax, %cl
+
+ movzbl %al, %cx
+ movzbl %ax, %cx
+ movzbl %eax, %cx
+
+ movzbl %al, %ecx
+ movzbl %ax, %ecx
+ movzbl %eax, %ecx
+
+ movzw %al, %cl
+ movzw %ax, %cl
+ movzw %eax, %cl
+
+ movzw %al, %cx
+ movzw %ax, %cx
+ movzw %eax, %cx
+
+ movzw %al, %ecx
+ movzw %ax, %ecx
+ movzw %eax, %ecx
+
+ movzwl %al, %cl
+ movzwl %ax, %cl
+ movzwl %eax, %cl
+
+ movzwl %al, %cx
+ movzwl %ax, %cx
+ movzwl %eax, %cx
+
+ movzwl %al, %ecx
+ movzwl %ax, %ecx
+ movzwl %eax, %ecx
+
+ .p2align 4
--- /dev/null
+++ b/gas/testsuite/gas/i386/movx64.l
@@ -0,0 +1,485 @@
+.*: Assembler messages:
+#...
+[ ]*[1-9][0-9]*[ ]+movsx:
+[ ]*[1-9][0-9]*[ ]+movsx %al, %cl
+[ ]*[1-9][0-9]*[ ]+movsx %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movsx %eax, %cl
+[ ]*[1-9][0-9]*[ ]+movsx %rax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 660FBEC8[ ]+movsx %al, %cx
+[ ]*[1-9][0-9]* \?\?\?\? 660FBFC8[ ]+movsx %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movsx %eax, %cx
+[ ]*[1-9][0-9]*[ ]+movsx %rax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 0FBEC8[ ]+movsx %al, %ecx
+[ ]*[1-9][0-9]* \?\?\?\? 0FBFC8[ ]+movsx %ax, %ecx
+[ ]*[1-9][0-9]* \?\?\?\? 63C8[ ]+movsx %eax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsx %rax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 480FBEC8[ ]+movsx %al, %rcx
+[ ]*[1-9][0-9]* \?\?\?\? 480FBFC8[ ]+movsx %ax, %rcx
+[ ]*[1-9][0-9]* \?\?\?\? 4863C8[ ]+movsx %eax, %rcx
+[ ]*[1-9][0-9]*[ ]+movsx %rax, %rcx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsxb %al, %cl
+[ ]*[1-9][0-9]*[ ]+movsxb %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movsxb %eax, %cl
+[ ]*[1-9][0-9]*[ ]+movsxb %rax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 660FBEC8[ ]+movsxb %al, %cx
+[ ]*[1-9][0-9]*[ ]+movsxb %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movsxb %eax, %cx
+[ ]*[1-9][0-9]*[ ]+movsxb %rax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 0FBEC8[ ]+movsxb %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movsxb %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsxb %eax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsxb %rax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 480FBEC8[ ]+movsxb %al, %rcx
+[ ]*[1-9][0-9]*[ ]+movsxb %ax, %rcx
+[ ]*[1-9][0-9]*[ ]+movsxb %eax, %rcx
+[ ]*[1-9][0-9]*[ ]+movsxb %rax, %rcx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsxw %al, %cl
+[ ]*[1-9][0-9]*[ ]+movsxw %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movsxw %eax, %cl
+[ ]*[1-9][0-9]*[ ]+movsxw %rax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsxw %al, %cx
+[ ]*[1-9][0-9]* \?\?\?\? 660FBFC8[ ]+movsxw %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movsxw %eax, %cx
+[ ]*[1-9][0-9]*[ ]+movsxw %rax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsxw %al, %ecx
+[ ]*[1-9][0-9]* \?\?\?\? 0FBFC8[ ]+movsxw %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsxw %eax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsxw %rax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsxw %al, %rcx
+[ ]*[1-9][0-9]* \?\?\?\? 480FBFC8[ ]+movsxw %ax, %rcx
+[ ]*[1-9][0-9]*[ ]+movsxw %eax, %rcx
+[ ]*[1-9][0-9]*[ ]+movsxw %rax, %rcx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsxl %al, %cl
+[ ]*[1-9][0-9]*[ ]+movsxl %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movsxl %eax, %cl
+[ ]*[1-9][0-9]*[ ]+movsxl %rax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsxl %al, %cx
+[ ]*[1-9][0-9]*[ ]+movsxl %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movsxl %eax, %cx
+[ ]*[1-9][0-9]*[ ]+movsxl %rax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsxl %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movsxl %ax, %ecx
+[ ]*[1-9][0-9]* \?\?\?\? 63C8[ ]+movsxl %eax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsxl %rax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsxl %al, %rcx
+[ ]*[1-9][0-9]*[ ]+movsxl %ax, %rcx
+[ ]*[1-9][0-9]* \?\?\?\? 4863C8[ ]+movsxl %eax, %rcx
+[ ]*[1-9][0-9]*[ ]+movsxl %rax, %rcx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsxd %al, %cl
+[ ]*[1-9][0-9]*[ ]+movsxd %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movsxd %eax, %cl
+[ ]*[1-9][0-9]*[ ]+movsxd %rax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsxd %al, %cx
+[ ]*[1-9][0-9]*[ ]+movsxd %ax, %cx
+[ ]*[1-9][0-9]* \?\?\?\? 6663C8[ ]+movsxd %eax, %cx
+[ ]*[1-9][0-9]*[ ]+movsxd %rax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsxd %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movsxd %ax, %ecx
+[ ]*[1-9][0-9]* \?\?\?\? 63C8[ ]+movsxd %eax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsxd %rax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsxd %al, %rcx
+[ ]*[1-9][0-9]*[ ]+movsxd %ax, %rcx
+[ ]*[1-9][0-9]* \?\?\?\? 4863C8[ ]+movsxd %eax, %rcx
+[ ]*[1-9][0-9]*[ ]+movsxd %rax, %rcx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsb %al, %cl
+[ ]*[1-9][0-9]*[ ]+movsb %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movsb %eax, %cl
+[ ]*[1-9][0-9]*[ ]+movsb %rax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsb %al, %cx
+[ ]*[1-9][0-9]*[ ]+movsb %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movsb %eax, %cx
+[ ]*[1-9][0-9]*[ ]+movsb %rax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsb %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movsb %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsb %eax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsb %rax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsb %al, %rcx
+[ ]*[1-9][0-9]*[ ]+movsb %ax, %rcx
+[ ]*[1-9][0-9]*[ ]+movsb %eax, %rcx
+[ ]*[1-9][0-9]*[ ]+movsb %rax, %rcx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsbw %al, %cl
+[ ]*[1-9][0-9]*[ ]+movsbw %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movsbw %eax, %cl
+[ ]*[1-9][0-9]*[ ]+movsbw %rax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 660FBEC8[ ]+movsbw %al, %cx
+[ ]*[1-9][0-9]*[ ]+movsbw %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movsbw %eax, %cx
+[ ]*[1-9][0-9]*[ ]+movsbw %rax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsbw %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movsbw %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsbw %eax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsbw %rax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsbw %al, %rcx
+[ ]*[1-9][0-9]*[ ]+movsbw %ax, %rcx
+[ ]*[1-9][0-9]*[ ]+movsbw %eax, %rcx
+[ ]*[1-9][0-9]*[ ]+movsbw %rax, %rcx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsbl %al, %cl
+[ ]*[1-9][0-9]*[ ]+movsbl %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movsbl %eax, %cl
+[ ]*[1-9][0-9]*[ ]+movsbl %rax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsbl %al, %cx
+[ ]*[1-9][0-9]*[ ]+movsbl %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movsbl %eax, %cx
+[ ]*[1-9][0-9]*[ ]+movsbl %rax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 0FBEC8[ ]+movsbl %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movsbl %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsbl %eax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsbl %rax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsbl %al, %rcx
+[ ]*[1-9][0-9]*[ ]+movsbl %ax, %rcx
+[ ]*[1-9][0-9]*[ ]+movsbl %eax, %rcx
+[ ]*[1-9][0-9]*[ ]+movsbl %rax, %rcx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsbq %al, %cl
+[ ]*[1-9][0-9]*[ ]+movsbq %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movsbq %eax, %cl
+[ ]*[1-9][0-9]*[ ]+movsbq %rax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsbq %al, %cx
+[ ]*[1-9][0-9]*[ ]+movsbq %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movsbq %eax, %cx
+[ ]*[1-9][0-9]*[ ]+movsbq %rax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsbq %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movsbq %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsbq %eax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsbq %rax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 480FBEC8[ ]+movsbq %al, %rcx
+[ ]*[1-9][0-9]*[ ]+movsbq %ax, %rcx
+[ ]*[1-9][0-9]*[ ]+movsbq %eax, %rcx
+[ ]*[1-9][0-9]*[ ]+movsbq %rax, %rcx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsw %al, %cl
+[ ]*[1-9][0-9]*[ ]+movsw %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movsw %eax, %cl
+[ ]*[1-9][0-9]*[ ]+movsw %rax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsw %al, %cx
+[ ]*[1-9][0-9]*[ ]+movsw %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movsw %eax, %cx
+[ ]*[1-9][0-9]*[ ]+movsw %rax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsw %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movsw %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsw %eax, %ecx
+[ ]*[1-9][0-9]*[ ]+movsw %rax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movsw %al, %rcx
+[ ]*[1-9][0-9]*[ ]+movsw %ax, %rcx
+[ ]*[1-9][0-9]*[ ]+movsw %eax, %rcx
+[ ]*[1-9][0-9]*[ ]+movsw %rax, %rcx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movswl %al, %cl
+[ ]*[1-9][0-9]*[ ]+movswl %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movswl %eax, %cl
+[ ]*[1-9][0-9]*[ ]+movswl %rax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movswl %al, %cx
+[ ]*[1-9][0-9]*[ ]+movswl %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movswl %eax, %cx
+[ ]*[1-9][0-9]*[ ]+movswl %rax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movswl %al, %ecx
+[ ]*[1-9][0-9]* \?\?\?\? 0FBFC8[ ]+movswl %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movswl %eax, %ecx
+[ ]*[1-9][0-9]*[ ]+movswl %rax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movswl %al, %rcx
+[ ]*[1-9][0-9]*[ ]+movswl %ax, %rcx
+[ ]*[1-9][0-9]*[ ]+movswl %eax, %rcx
+[ ]*[1-9][0-9]*[ ]+movswl %rax, %rcx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movswq %al, %cl
+[ ]*[1-9][0-9]*[ ]+movswq %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movswq %eax, %cl
+[ ]*[1-9][0-9]*[ ]+movswq %rax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movswq %al, %cx
+[ ]*[1-9][0-9]*[ ]+movswq %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movswq %eax, %cx
+[ ]*[1-9][0-9]*[ ]+movswq %rax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movswq %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movswq %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movswq %eax, %ecx
+[ ]*[1-9][0-9]*[ ]+movswq %rax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movswq %al, %rcx
+[ ]*[1-9][0-9]* \?\?\?\? 480FBFC8[ ]+movswq %ax, %rcx
+[ ]*[1-9][0-9]*[ ]+movswq %eax, %rcx
+[ ]*[1-9][0-9]*[ ]+movswq %rax, %rcx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzx:
+[ ]*[1-9][0-9]*[ ]+movzx %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzx %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzx %eax, %cl
+[ ]*[1-9][0-9]*[ ]+movzx %rax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 660FB6C8[ ]+movzx %al, %cx
+[ ]*[1-9][0-9]* \?\?\?\? 660FB7C8[ ]+movzx %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzx %eax, %cx
+[ ]*[1-9][0-9]*[ ]+movzx %rax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 0FB6C8[ ]+movzx %al, %ecx
+[ ]*[1-9][0-9]* \?\?\?\? 0FB7C8[ ]+movzx %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzx %eax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzx %rax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 480FB6C8[ ]+movzx %al, %rcx
+[ ]*[1-9][0-9]* \?\?\?\? 480FB7C8[ ]+movzx %ax, %rcx
+[ ]*[1-9][0-9]*[ ]+movzx %eax, %rcx
+[ ]*[1-9][0-9]*[ ]+movzx %rax, %rcx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzxb %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzxb %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzxb %eax, %cl
+[ ]*[1-9][0-9]*[ ]+movzxb %rax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 660FB6C8[ ]+movzxb %al, %cx
+[ ]*[1-9][0-9]*[ ]+movzxb %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzxb %eax, %cx
+[ ]*[1-9][0-9]*[ ]+movzxb %rax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 0FB6C8[ ]+movzxb %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movzxb %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzxb %eax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzxb %rax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 480FB6C8[ ]+movzxb %al, %rcx
+[ ]*[1-9][0-9]*[ ]+movzxb %ax, %rcx
+[ ]*[1-9][0-9]*[ ]+movzxb %eax, %rcx
+[ ]*[1-9][0-9]*[ ]+movzxb %rax, %rcx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzxw %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzxw %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzxw %eax, %cl
+[ ]*[1-9][0-9]*[ ]+movzxw %rax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzxw %al, %cx
+[ ]*[1-9][0-9]* \?\?\?\? 660FB7C8[ ]+movzxw %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzxw %eax, %cx
+[ ]*[1-9][0-9]*[ ]+movzxw %rax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzxw %al, %ecx
+[ ]*[1-9][0-9]* \?\?\?\? 0FB7C8[ ]+movzxw %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzxw %eax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzxw %rax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzxw %al, %rcx
+[ ]*[1-9][0-9]* \?\?\?\? 480FB7C8[ ]+movzxw %ax, %rcx
+[ ]*[1-9][0-9]*[ ]+movzxw %eax, %rcx
+[ ]*[1-9][0-9]*[ ]+movzxw %rax, %rcx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzxl %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzxl %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzxl %eax, %cl
+[ ]*[1-9][0-9]*[ ]+movzxl %rax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzxl %al, %cx
+[ ]*[1-9][0-9]*[ ]+movzxl %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzxl %eax, %cx
+[ ]*[1-9][0-9]*[ ]+movzxl %rax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzxl %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movzxl %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzxl %eax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzxl %rax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzxl %al, %rcx
+[ ]*[1-9][0-9]*[ ]+movzxl %ax, %rcx
+[ ]*[1-9][0-9]*[ ]+movzxl %eax, %rcx
+[ ]*[1-9][0-9]*[ ]+movzxl %rax, %rcx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzxd %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzxd %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzxd %eax, %cl
+[ ]*[1-9][0-9]*[ ]+movzxd %rax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzxd %al, %cx
+[ ]*[1-9][0-9]*[ ]+movzxd %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzxd %eax, %cx
+[ ]*[1-9][0-9]*[ ]+movzxd %rax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzxd %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movzxd %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzxd %eax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzxd %rax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzxd %al, %rcx
+[ ]*[1-9][0-9]*[ ]+movzxd %ax, %rcx
+[ ]*[1-9][0-9]*[ ]+movzxd %eax, %rcx
+[ ]*[1-9][0-9]*[ ]+movzxd %rax, %rcx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzb %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzb %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzb %eax, %cl
+[ ]*[1-9][0-9]*[ ]+movzb %rax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 660FB6C8[ ]+movzb %al, %cx
+[ ]*[1-9][0-9]*[ ]+movzb %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzb %eax, %cx
+[ ]*[1-9][0-9]*[ ]+movzb %rax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 0FB6C8[ ]+movzb %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movzb %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzb %eax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzb %rax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 480FB6C8[ ]+movzb %al, %rcx
+[ ]*[1-9][0-9]*[ ]+movzb %ax, %rcx
+[ ]*[1-9][0-9]*[ ]+movzb %eax, %rcx
+[ ]*[1-9][0-9]*[ ]+movzb %rax, %rcx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzbw %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzbw %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzbw %eax, %cl
+[ ]*[1-9][0-9]*[ ]+movzbw %rax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 660FB6C8[ ]+movzbw %al, %cx
+[ ]*[1-9][0-9]*[ ]+movzbw %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzbw %eax, %cx
+[ ]*[1-9][0-9]*[ ]+movzbw %rax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzbw %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movzbw %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzbw %eax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzbw %rax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzbw %al, %rcx
+[ ]*[1-9][0-9]*[ ]+movzbw %ax, %rcx
+[ ]*[1-9][0-9]*[ ]+movzbw %eax, %rcx
+[ ]*[1-9][0-9]*[ ]+movzbw %rax, %rcx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzbl %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzbl %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzbl %eax, %cl
+[ ]*[1-9][0-9]*[ ]+movzbl %rax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzbl %al, %cx
+[ ]*[1-9][0-9]*[ ]+movzbl %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzbl %eax, %cx
+[ ]*[1-9][0-9]*[ ]+movzbl %rax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 0FB6C8[ ]+movzbl %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movzbl %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzbl %eax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzbl %rax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzbl %al, %rcx
+[ ]*[1-9][0-9]*[ ]+movzbl %ax, %rcx
+[ ]*[1-9][0-9]*[ ]+movzbl %eax, %rcx
+[ ]*[1-9][0-9]*[ ]+movzbl %rax, %rcx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzbq %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzbq %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzbq %eax, %cl
+[ ]*[1-9][0-9]*[ ]+movzbq %rax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzbq %al, %cx
+[ ]*[1-9][0-9]*[ ]+movzbq %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzbq %eax, %cx
+[ ]*[1-9][0-9]*[ ]+movzbq %rax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzbq %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movzbq %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzbq %eax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzbq %rax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]* \?\?\?\? 480FB6C8[ ]+movzbq %al, %rcx
+[ ]*[1-9][0-9]*[ ]+movzbq %ax, %rcx
+[ ]*[1-9][0-9]*[ ]+movzbq %eax, %rcx
+[ ]*[1-9][0-9]*[ ]+movzbq %rax, %rcx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzw %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzw %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzw %eax, %cl
+[ ]*[1-9][0-9]*[ ]+movzw %rax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzw %al, %cx
+[ ]*[1-9][0-9]*[ ]+movzw %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzw %eax, %cx
+[ ]*[1-9][0-9]*[ ]+movzw %rax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzw %al, %ecx
+[ ]*[1-9][0-9]* \?\?\?\? 0FB7C8[ ]+movzw %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzw %eax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzw %rax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzw %al, %rcx
+[ ]*[1-9][0-9]* \?\?\?\? 480FB7C8[ ]+movzw %ax, %rcx
+[ ]*[1-9][0-9]*[ ]+movzw %eax, %rcx
+[ ]*[1-9][0-9]*[ ]+movzw %rax, %rcx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzwl %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzwl %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzwl %eax, %cl
+[ ]*[1-9][0-9]*[ ]+movzwl %rax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzwl %al, %cx
+[ ]*[1-9][0-9]*[ ]+movzwl %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzwl %eax, %cx
+[ ]*[1-9][0-9]*[ ]+movzwl %rax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzwl %al, %ecx
+[ ]*[1-9][0-9]* \?\?\?\? 0FB7C8[ ]+movzwl %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzwl %eax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzwl %rax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzwl %al, %rcx
+[ ]*[1-9][0-9]*[ ]+movzwl %ax, %rcx
+[ ]*[1-9][0-9]*[ ]+movzwl %eax, %rcx
+[ ]*[1-9][0-9]*[ ]+movzwl %rax, %rcx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzwq %al, %cl
+[ ]*[1-9][0-9]*[ ]+movzwq %ax, %cl
+[ ]*[1-9][0-9]*[ ]+movzwq %eax, %cl
+[ ]*[1-9][0-9]*[ ]+movzwq %rax, %cl
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzwq %al, %cx
+[ ]*[1-9][0-9]*[ ]+movzwq %ax, %cx
+[ ]*[1-9][0-9]*[ ]+movzwq %eax, %cx
+[ ]*[1-9][0-9]*[ ]+movzwq %rax, %cx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzwq %al, %ecx
+[ ]*[1-9][0-9]*[ ]+movzwq %ax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzwq %eax, %ecx
+[ ]*[1-9][0-9]*[ ]+movzwq %rax, %ecx
+[ ]*[1-9][0-9]*[ ]*
+[ ]*[1-9][0-9]*[ ]+movzwq %al, %rcx
+[ ]*[1-9][0-9]* \?\?\?\? 480FB7C8[ ]+movzwq %ax, %rcx
+[ ]*[1-9][0-9]*[ ]+movzwq %eax, %rcx
+[ ]*[1-9][0-9]*[ ]+movzwq %rax, %rcx
+[ ]*[1-9][0-9]*[ ]*
+#pass
--- /dev/null
+++ b/gas/testsuite/gas/i386/movx64.s
@@ -0,0 +1,485 @@
+ .text
+ .psize 0
+movsx:
+ movsx %al, %cl
+ movsx %ax, %cl
+ movsx %eax, %cl
+ movsx %rax, %cl
+
+ movsx %al, %cx
+ movsx %ax, %cx
+ movsx %eax, %cx
+ movsx %rax, %cx
+
+ movsx %al, %ecx
+ movsx %ax, %ecx
+ movsx %eax, %ecx
+ movsx %rax, %ecx
+
+ movsx %al, %rcx
+ movsx %ax, %rcx
+ movsx %eax, %rcx
+ movsx %rax, %rcx
+
+ movsxb %al, %cl
+ movsxb %ax, %cl
+ movsxb %eax, %cl
+ movsxb %rax, %cl
+
+ movsxb %al, %cx
+ movsxb %ax, %cx
+ movsxb %eax, %cx
+ movsxb %rax, %cx
+
+ movsxb %al, %ecx
+ movsxb %ax, %ecx
+ movsxb %eax, %ecx
+ movsxb %rax, %ecx
+
+ movsxb %al, %rcx
+ movsxb %ax, %rcx
+ movsxb %eax, %rcx
+ movsxb %rax, %rcx
+
+ movsxw %al, %cl
+ movsxw %ax, %cl
+ movsxw %eax, %cl
+ movsxw %rax, %cl
+
+ movsxw %al, %cx
+ movsxw %ax, %cx
+ movsxw %eax, %cx
+ movsxw %rax, %cx
+
+ movsxw %al, %ecx
+ movsxw %ax, %ecx
+ movsxw %eax, %ecx
+ movsxw %rax, %ecx
+
+ movsxw %al, %rcx
+ movsxw %ax, %rcx
+ movsxw %eax, %rcx
+ movsxw %rax, %rcx
+
+ movsxl %al, %cl
+ movsxl %ax, %cl
+ movsxl %eax, %cl
+ movsxl %rax, %cl
+
+ movsxl %al, %cx
+ movsxl %ax, %cx
+ movsxl %eax, %cx
+ movsxl %rax, %cx
+
+ movsxl %al, %ecx
+ movsxl %ax, %ecx
+ movsxl %eax, %ecx
+ movsxl %rax, %ecx
+
+ movsxl %al, %rcx
+ movsxl %ax, %rcx
+ movsxl %eax, %rcx
+ movsxl %rax, %rcx
+
+ movsxd %al, %cl
+ movsxd %ax, %cl
+ movsxd %eax, %cl
+ movsxd %rax, %cl
+
+ movsxd %al, %cx
+ movsxd %ax, %cx
+ movsxd %eax, %cx
+ movsxd %rax, %cx
+
+ movsxd %al, %ecx
+ movsxd %ax, %ecx
+ movsxd %eax, %ecx
+ movsxd %rax, %ecx
+
+ movsxd %al, %rcx
+ movsxd %ax, %rcx
+ movsxd %eax, %rcx
+ movsxd %rax, %rcx
+
+ movsb %al, %cl
+ movsb %ax, %cl
+ movsb %eax, %cl
+ movsb %rax, %cl
+
+ movsb %al, %cx
+ movsb %ax, %cx
+ movsb %eax, %cx
+ movsb %rax, %cx
+
+ movsb %al, %ecx
+ movsb %ax, %ecx
+ movsb %eax, %ecx
+ movsb %rax, %ecx
+
+ movsb %al, %rcx
+ movsb %ax, %rcx
+ movsb %eax, %rcx
+ movsb %rax, %rcx
+
+ movsbw %al, %cl
+ movsbw %ax, %cl
+ movsbw %eax, %cl
+ movsbw %rax, %cl
+
+ movsbw %al, %cx
+ movsbw %ax, %cx
+ movsbw %eax, %cx
+ movsbw %rax, %cx
+
+ movsbw %al, %ecx
+ movsbw %ax, %ecx
+ movsbw %eax, %ecx
+ movsbw %rax, %ecx
+
+ movsbw %al, %rcx
+ movsbw %ax, %rcx
+ movsbw %eax, %rcx
+ movsbw %rax, %rcx
+
+ movsbl %al, %cl
+ movsbl %ax, %cl
+ movsbl %eax, %cl
+ movsbl %rax, %cl
+
+ movsbl %al, %cx
+ movsbl %ax, %cx
+ movsbl %eax, %cx
+ movsbl %rax, %cx
+
+ movsbl %al, %ecx
+ movsbl %ax, %ecx
+ movsbl %eax, %ecx
+ movsbl %rax, %ecx
+
+ movsbl %al, %rcx
+ movsbl %ax, %rcx
+ movsbl %eax, %rcx
+ movsbl %rax, %rcx
+
+ movsbq %al, %cl
+ movsbq %ax, %cl
+ movsbq %eax, %cl
+ movsbq %rax, %cl
+
+ movsbq %al, %cx
+ movsbq %ax, %cx
+ movsbq %eax, %cx
+ movsbq %rax, %cx
+
+ movsbq %al, %ecx
+ movsbq %ax, %ecx
+ movsbq %eax, %ecx
+ movsbq %rax, %ecx
+
+ movsbq %al, %rcx
+ movsbq %ax, %rcx
+ movsbq %eax, %rcx
+ movsbq %rax, %rcx
+
+ movsw %al, %cl
+ movsw %ax, %cl
+ movsw %eax, %cl
+ movsw %rax, %cl
+
+ movsw %al, %cx
+ movsw %ax, %cx
+ movsw %eax, %cx
+ movsw %rax, %cx
+
+ movsw %al, %ecx
+ movsw %ax, %ecx
+ movsw %eax, %ecx
+ movsw %rax, %ecx
+
+ movsw %al, %rcx
+ movsw %ax, %rcx
+ movsw %eax, %rcx
+ movsw %rax, %rcx
+
+ movswl %al, %cl
+ movswl %ax, %cl
+ movswl %eax, %cl
+ movswl %rax, %cl
+
+ movswl %al, %cx
+ movswl %ax, %cx
+ movswl %eax, %cx
+ movswl %rax, %cx
+
+ movswl %al, %ecx
+ movswl %ax, %ecx
+ movswl %eax, %ecx
+ movswl %rax, %ecx
+
+ movswl %al, %rcx
+ movswl %ax, %rcx
+ movswl %eax, %rcx
+ movswl %rax, %rcx
+
+ movswq %al, %cl
+ movswq %ax, %cl
+ movswq %eax, %cl
+ movswq %rax, %cl
+
+ movswq %al, %cx
+ movswq %ax, %cx
+ movswq %eax, %cx
+ movswq %rax, %cx
+
+ movswq %al, %ecx
+ movswq %ax, %ecx
+ movswq %eax, %ecx
+ movswq %rax, %ecx
+
+ movswq %al, %rcx
+ movswq %ax, %rcx
+ movswq %eax, %rcx
+ movswq %rax, %rcx
+
+movzx:
+ movzx %al, %cl
+ movzx %ax, %cl
+ movzx %eax, %cl
+ movzx %rax, %cl
+
+ movzx %al, %cx
+ movzx %ax, %cx
+ movzx %eax, %cx
+ movzx %rax, %cx
+
+ movzx %al, %ecx
+ movzx %ax, %ecx
+ movzx %eax, %ecx
+ movzx %rax, %ecx
+
+ movzx %al, %rcx
+ movzx %ax, %rcx
+ movzx %eax, %rcx
+ movzx %rax, %rcx
+
+ movzxb %al, %cl
+ movzxb %ax, %cl
+ movzxb %eax, %cl
+ movzxb %rax, %cl
+
+ movzxb %al, %cx
+ movzxb %ax, %cx
+ movzxb %eax, %cx
+ movzxb %rax, %cx
+
+ movzxb %al, %ecx
+ movzxb %ax, %ecx
+ movzxb %eax, %ecx
+ movzxb %rax, %ecx
+
+ movzxb %al, %rcx
+ movzxb %ax, %rcx
+ movzxb %eax, %rcx
+ movzxb %rax, %rcx
+
+ movzxw %al, %cl
+ movzxw %ax, %cl
+ movzxw %eax, %cl
+ movzxw %rax, %cl
+
+ movzxw %al, %cx
+ movzxw %ax, %cx
+ movzxw %eax, %cx
+ movzxw %rax, %cx
+
+ movzxw %al, %ecx
+ movzxw %ax, %ecx
+ movzxw %eax, %ecx
+ movzxw %rax, %ecx
+
+ movzxw %al, %rcx
+ movzxw %ax, %rcx
+ movzxw %eax, %rcx
+ movzxw %rax, %rcx
+
+ movzxl %al, %cl
+ movzxl %ax, %cl
+ movzxl %eax, %cl
+ movzxl %rax, %cl
+
+ movzxl %al, %cx
+ movzxl %ax, %cx
+ movzxl %eax, %cx
+ movzxl %rax, %cx
+
+ movzxl %al, %ecx
+ movzxl %ax, %ecx
+ movzxl %eax, %ecx
+ movzxl %rax, %ecx
+
+ movzxl %al, %rcx
+ movzxl %ax, %rcx
+ movzxl %eax, %rcx
+ movzxl %rax, %rcx
+
+ movzxd %al, %cl
+ movzxd %ax, %cl
+ movzxd %eax, %cl
+ movzxd %rax, %cl
+
+ movzxd %al, %cx
+ movzxd %ax, %cx
+ movzxd %eax, %cx
+ movzxd %rax, %cx
+
+ movzxd %al, %ecx
+ movzxd %ax, %ecx
+ movzxd %eax, %ecx
+ movzxd %rax, %ecx
+
+ movzxd %al, %rcx
+ movzxd %ax, %rcx
+ movzxd %eax, %rcx
+ movzxd %rax, %rcx
+
+ movzb %al, %cl
+ movzb %ax, %cl
+ movzb %eax, %cl
+ movzb %rax, %cl
+
+ movzb %al, %cx
+ movzb %ax, %cx
+ movzb %eax, %cx
+ movzb %rax, %cx
+
+ movzb %al, %ecx
+ movzb %ax, %ecx
+ movzb %eax, %ecx
+ movzb %rax, %ecx
+
+ movzb %al, %rcx
+ movzb %ax, %rcx
+ movzb %eax, %rcx
+ movzb %rax, %rcx
+
+ movzbw %al, %cl
+ movzbw %ax, %cl
+ movzbw %eax, %cl
+ movzbw %rax, %cl
+
+ movzbw %al, %cx
+ movzbw %ax, %cx
+ movzbw %eax, %cx
+ movzbw %rax, %cx
+
+ movzbw %al, %ecx
+ movzbw %ax, %ecx
+ movzbw %eax, %ecx
+ movzbw %rax, %ecx
+
+ movzbw %al, %rcx
+ movzbw %ax, %rcx
+ movzbw %eax, %rcx
+ movzbw %rax, %rcx
+
+ movzbl %al, %cl
+ movzbl %ax, %cl
+ movzbl %eax, %cl
+ movzbl %rax, %cl
+
+ movzbl %al, %cx
+ movzbl %ax, %cx
+ movzbl %eax, %cx
+ movzbl %rax, %cx
+
+ movzbl %al, %ecx
+ movzbl %ax, %ecx
+ movzbl %eax, %ecx
+ movzbl %rax, %ecx
+
+ movzbl %al, %rcx
+ movzbl %ax, %rcx
+ movzbl %eax, %rcx
+ movzbl %rax, %rcx
+
+ movzbq %al, %cl
+ movzbq %ax, %cl
+ movzbq %eax, %cl
+ movzbq %rax, %cl
+
+ movzbq %al, %cx
+ movzbq %ax, %cx
+ movzbq %eax, %cx
+ movzbq %rax, %cx
+
+ movzbq %al, %ecx
+ movzbq %ax, %ecx
+ movzbq %eax, %ecx
+ movzbq %rax, %ecx
+
+ movzbq %al, %rcx
+ movzbq %ax, %rcx
+ movzbq %eax, %rcx
+ movzbq %rax, %rcx
+
+ movzw %al, %cl
+ movzw %ax, %cl
+ movzw %eax, %cl
+ movzw %rax, %cl
+
+ movzw %al, %cx
+ movzw %ax, %cx
+ movzw %eax, %cx
+ movzw %rax, %cx
+
+ movzw %al, %ecx
+ movzw %ax, %ecx
+ movzw %eax, %ecx
+ movzw %rax, %ecx
+
+ movzw %al, %rcx
+ movzw %ax, %rcx
+ movzw %eax, %rcx
+ movzw %rax, %rcx
+
+ movzwl %al, %cl
+ movzwl %ax, %cl
+ movzwl %eax, %cl
+ movzwl %rax, %cl
+
+ movzwl %al, %cx
+ movzwl %ax, %cx
+ movzwl %eax, %cx
+ movzwl %rax, %cx
+
+ movzwl %al, %ecx
+ movzwl %ax, %ecx
+ movzwl %eax, %ecx
+ movzwl %rax, %ecx
+
+ movzwl %al, %rcx
+ movzwl %ax, %rcx
+ movzwl %eax, %rcx
+ movzwl %rax, %rcx
+
+ movzwq %al, %cl
+ movzwq %ax, %cl
+ movzwq %eax, %cl
+ movzwq %rax, %cl
+
+ movzwq %al, %cx
+ movzwq %ax, %cx
+ movzwq %eax, %cx
+ movzwq %rax, %cx
+
+ movzwq %al, %ecx
+ movzwq %ax, %ecx
+ movzwq %eax, %ecx
+ movzwq %rax, %ecx
+
+ movzwq %al, %rcx
+ movzwq %ax, %rcx
+ movzwq %eax, %rcx
+ movzwq %rax, %rcx
+
+ .p2align 4
--- a/gas/testsuite/gas/i386/noreg16.d
+++ b/gas/testsuite/gas/i386/noreg16.d
@@ -75,6 +75,10 @@ Disassembly of section .text:
*[a-f0-9]+: 8e 07 mov \(%bx\),%es
*[a-f0-9]+: a5 movsw %ds:\(%si\),%es:\(%di\)
*[a-f0-9]+: 67 a5 movsw %ds:\(%esi\),%es:\(%edi\)
+ *[a-f0-9]+: 0f be 07 movsbw \(%bx\),%ax
+ *[a-f0-9]+: 66 0f be 07 movsbl \(%bx\),%eax
+ *[a-f0-9]+: 0f b6 07 movzbw \(%bx\),%ax
+ *[a-f0-9]+: 66 0f b6 07 movzbl \(%bx\),%eax
*[a-f0-9]+: f7 27 mulw \(%bx\)
*[a-f0-9]+: f7 1f negw \(%bx\)
*[a-f0-9]+: 0f 1f 07 nopw \(%bx\)
--- a/gas/testsuite/gas/i386/noreg16.s
+++ b/gas/testsuite/gas/i386/noreg16.s
@@ -69,6 +69,10 @@ noreg:
mov (%bx), %es
movs
movs (%esi), %es:(%edi)
+ movsx (%bx), %ax
+ movsx (%bx), %eax
+ movzx (%bx), %ax
+ movzx (%bx), %eax
mul (%bx)
neg (%bx)
nop (%bx)
--- a/gas/testsuite/gas/i386/noreg32.d
+++ b/gas/testsuite/gas/i386/noreg32.d
@@ -80,6 +80,10 @@ Disassembly of section .text:
*[a-f0-9]+: 8e 00 mov \(%eax\),%es
*[a-f0-9]+: a5 movsl %ds:\(%esi\),%es:\(%edi\)
*[a-f0-9]+: a5 movsl %ds:\(%esi\),%es:\(%edi\)
+ *[a-f0-9]+: 66 0f be 00 movsbw \(%eax\),%ax
+ *[a-f0-9]+: 0f be 00 movsbl \(%eax\),%eax
+ *[a-f0-9]+: 66 0f b6 00 movzbw \(%eax\),%ax
+ *[a-f0-9]+: 0f b6 00 movzbl \(%eax\),%eax
*[a-f0-9]+: f7 20 mull \(%eax\)
*[a-f0-9]+: f7 18 negl \(%eax\)
*[a-f0-9]+: 0f 1f 00 nopl \(%eax\)
--- a/gas/testsuite/gas/i386/noreg32.s
+++ b/gas/testsuite/gas/i386/noreg32.s
@@ -73,6 +73,10 @@ noreg:
mov (%eax), %es
movs
movs (%esi), %es:(%edi)
+ movsx (%eax), %ax
+ movsx (%eax), %eax
+ movzx (%eax), %ax
+ movzx (%eax), %eax
mul (%eax)
neg (%eax)
nop (%eax)
--- a/gas/testsuite/gas/i386/noreg64.d
+++ b/gas/testsuite/gas/i386/noreg64.d
@@ -84,6 +84,12 @@ Disassembly of section .text:
*[a-f0-9]+: 8e 00 mov \(%rax\),%es
*[a-f0-9]+: a5 movsl %ds:\(%rsi\),%es:\(%rdi\)
*[a-f0-9]+: a5 movsl %ds:\(%rsi\),%es:\(%rdi\)
+ *[a-f0-9]+: 66 0f be 00 movsbw \(%rax\),%ax
+ *[a-f0-9]+: 0f be 00 movsbl \(%rax\),%eax
+ *[a-f0-9]+: 48 0f be 00 movsbq \(%rax\),%rax
+ *[a-f0-9]+: 66 0f b6 00 movzbw \(%rax\),%ax
+ *[a-f0-9]+: 0f b6 00 movzbl \(%rax\),%eax
+ *[a-f0-9]+: 48 0f b6 00 movzbq \(%rax\),%rax
*[a-f0-9]+: f7 20 mull \(%rax\)
*[a-f0-9]+: f7 18 negl \(%rax\)
*[a-f0-9]+: 0f 1f 00 nopl \(%rax\)
--- a/gas/testsuite/gas/i386/noreg64.s
+++ b/gas/testsuite/gas/i386/noreg64.s
@@ -77,6 +77,12 @@ noreg:
mov (%rax), %es
movs
movs (%rsi), %es:(%rdi)
+ movsx (%rax), %ax
+ movsx (%rax), %eax
+ movsx (%rax), %rax
+ movzx (%rax), %ax
+ movzx (%rax), %eax
+ movzx (%rax), %rax
mul (%rax)
neg (%rax)
nop (%rax)
--- a/gas/testsuite/gas/i386/x86-64-movsxd-intel.d
+++ b/gas/testsuite/gas/i386/x86-64-movsxd-intel.d
@@ -21,6 +21,6 @@ Disassembly of section .text:
+[a-f0-9]+: 63 08 movsxd ecx,DWORD PTR \[rax\]
+[a-f0-9]+: 63 08 movsxd ecx,DWORD PTR \[rax\]
+[a-f0-9]+: 66 63 c8 movsxd cx,eax
- +[a-f0-9]+: 63 08 movsxd ecx,DWORD PTR \[rax\]
+ +[a-f0-9]+: 66 63 08 movsxd cx,DWORD PTR \[rax\]
+[a-f0-9]+: 66 63 08 movsxd cx,DWORD PTR \[rax\]
#pass
--- a/gas/testsuite/gas/i386/x86-64-movsxd.d
+++ b/gas/testsuite/gas/i386/x86-64-movsxd.d
@@ -20,6 +20,6 @@ Disassembly of section .text:
+[a-f0-9]+: 63 08 movsxd \(%rax\),%ecx
+[a-f0-9]+: 63 08 movsxd \(%rax\),%ecx
+[a-f0-9]+: 66 63 c8 movsxd %eax,%cx
- +[a-f0-9]+: 63 08 movsxd \(%rax\),%ecx
+ +[a-f0-9]+: 66 63 08 movsxd \(%rax\),%cx
+[a-f0-9]+: 66 63 08 movsxd \(%rax\),%cx
#pass
--- a/gas/testsuite/gas/i386/x86_64-intel.d
+++ b/gas/testsuite/gas/i386/x86_64-intel.d
@@ -173,8 +173,6 @@ Disassembly of section .text:
[ ]*[a-f0-9]+: 0f bf f0 movsx esi,ax
[ ]*[a-f0-9]+: 48 0f bf f0 movsx rsi,ax
[ ]*[a-f0-9]+: 48 63 f0 movsxd rsi,eax
-[ ]*[a-f0-9]+: 0f be 10 movsx edx,BYTE PTR \[rax\]
-[ ]*[a-f0-9]+: 48 0f be 10 movsx rdx,BYTE PTR \[rax\]
[ ]*[a-f0-9]+: 66 0f be 10 movsx dx,BYTE PTR \[rax\]
[ ]*[a-f0-9]+: 0f be 10 movsx edx,BYTE PTR \[rax\]
[ ]*[a-f0-9]+: 48 0f be 10 movsx rdx,BYTE PTR \[rax\]
@@ -186,8 +184,6 @@ Disassembly of section .text:
[ ]*[a-f0-9]+: 48 0f b6 f0 movzx rsi,al
[ ]*[a-f0-9]+: 0f b7 f0 movzx esi,ax
[ ]*[a-f0-9]+: 48 0f b7 f0 movzx rsi,ax
-[ ]*[a-f0-9]+: 0f b6 10 movzx edx,BYTE PTR \[rax\]
-[ ]*[a-f0-9]+: 48 0f b6 10 movzx rdx,BYTE PTR \[rax\]
[ ]*[a-f0-9]+: 66 0f b6 10 movzx dx,BYTE PTR \[rax\]
[ ]*[a-f0-9]+: 0f b6 10 movzx edx,BYTE PTR \[rax\]
[ ]*[a-f0-9]+: 48 0f b6 10 movzx rdx,BYTE PTR \[rax\]
@@ -231,8 +227,6 @@ Disassembly of section .text:
[ ]*[a-f0-9]+: 9b df e0 fstsw ax
[ ]*[a-f0-9]+: 9b df e0 fstsw ax
[ ]*[a-f0-9]+: 66 0f be 00 movsx ax,BYTE PTR \[rax\]
-[ ]*[a-f0-9]+: 0f be 00 movsx eax,BYTE PTR \[rax\]
-[ ]*[a-f0-9]+: 48 0f be 00 movsx rax,BYTE PTR \[rax\]
[ ]*[a-f0-9]+: 66 0f be 10 movsx dx,BYTE PTR \[rax\]
[ ]*[a-f0-9]+: 0f be 10 movsx edx,BYTE PTR \[rax\]
[ ]*[a-f0-9]+: 48 0f be 10 movsx rdx,BYTE PTR \[rax\]
@@ -241,8 +235,6 @@ Disassembly of section .text:
[ ]*[a-f0-9]+: 48 63 10 movsxd rdx,DWORD PTR \[rax\]
[ ]*[a-f0-9]+: 48 63 00 movsxd rax,DWORD PTR \[rax\]
[ ]*[a-f0-9]+: 66 0f b6 00 movzx ax,BYTE PTR \[rax\]
-[ ]*[a-f0-9]+: 0f b6 00 movzx eax,BYTE PTR \[rax\]
-[ ]*[a-f0-9]+: 48 0f b6 00 movzx rax,BYTE PTR \[rax\]
[ ]*[a-f0-9]+: 66 0f b6 10 movzx dx,BYTE PTR \[rax\]
[ ]*[a-f0-9]+: 0f b6 10 movzx edx,BYTE PTR \[rax\]
[ ]*[a-f0-9]+: 48 0f b6 10 movzx rdx,BYTE PTR \[rax\]
--- a/gas/testsuite/gas/i386/x86_64.d
+++ b/gas/testsuite/gas/i386/x86_64.d
@@ -173,8 +173,6 @@ Disassembly of section .text:
[ ]*[a-f0-9]+: 0f bf f0 movswl %ax,%esi
[ ]*[a-f0-9]+: 48 0f bf f0 movswq %ax,%rsi
[ ]*[a-f0-9]+: 48 63 f0 movslq %eax,%rsi
-[ ]*[a-f0-9]+: 0f be 10 movsbl \(%rax\),%edx
-[ ]*[a-f0-9]+: 48 0f be 10 movsbq \(%rax\),%rdx
[ ]*[a-f0-9]+: 66 0f be 10 movsbw \(%rax\),%dx
[ ]*[a-f0-9]+: 0f be 10 movsbl \(%rax\),%edx
[ ]*[a-f0-9]+: 48 0f be 10 movsbq \(%rax\),%rdx
@@ -186,8 +184,6 @@ Disassembly of section .text:
[ ]*[a-f0-9]+: 48 0f b6 f0 movzbq %al,%rsi
[ ]*[a-f0-9]+: 0f b7 f0 movzwl %ax,%esi
[ ]*[a-f0-9]+: 48 0f b7 f0 movzwq %ax,%rsi
-[ ]*[a-f0-9]+: 0f b6 10 movzbl \(%rax\),%edx
-[ ]*[a-f0-9]+: 48 0f b6 10 movzbq \(%rax\),%rdx
[ ]*[a-f0-9]+: 66 0f b6 10 movzbw \(%rax\),%dx
[ ]*[a-f0-9]+: 0f b6 10 movzbl \(%rax\),%edx
[ ]*[a-f0-9]+: 48 0f b6 10 movzbq \(%rax\),%rdx
@@ -231,8 +227,6 @@ Disassembly of section .text:
[ ]*[a-f0-9]+: 9b df e0 fstsw %ax
[ ]*[a-f0-9]+: 9b df e0 fstsw %ax
[ ]*[a-f0-9]+: 66 0f be 00 movsbw \(%rax\),%ax
-[ ]*[a-f0-9]+: 0f be 00 movsbl \(%rax\),%eax
-[ ]*[a-f0-9]+: 48 0f be 00 movsbq \(%rax\),%rax
[ ]*[a-f0-9]+: 66 0f be 10 movsbw \(%rax\),%dx
[ ]*[a-f0-9]+: 0f be 10 movsbl \(%rax\),%edx
[ ]*[a-f0-9]+: 48 0f be 10 movsbq \(%rax\),%rdx
@@ -241,8 +235,6 @@ Disassembly of section .text:
[ ]*[a-f0-9]+: 48 63 10 movslq \(%rax\),%rdx
[ ]*[a-f0-9]+: 48 63 00 movslq \(%rax\),%rax
[ ]*[a-f0-9]+: 66 0f b6 00 movzbw \(%rax\),%ax
-[ ]*[a-f0-9]+: 0f b6 00 movzbl \(%rax\),%eax
-[ ]*[a-f0-9]+: 48 0f b6 00 movzbq \(%rax\),%rax
[ ]*[a-f0-9]+: 66 0f b6 10 movzbw \(%rax\),%dx
[ ]*[a-f0-9]+: 0f b6 10 movzbl \(%rax\),%edx
[ ]*[a-f0-9]+: 48 0f b6 10 movzbq \(%rax\),%rdx
--- a/gas/testsuite/gas/i386/x86_64.s
+++ b/gas/testsuite/gas/i386/x86_64.s
@@ -208,8 +208,6 @@ cmpxchg16b oword ptr [rax]
movsx %ax, %esi
movsx %ax, %rsi
movsx %eax, %rsi
- movsx (%rax), %edx
- movsx (%rax), %rdx
movsx (%rax), %dx
movsbl (%rax), %edx
movsbq (%rax), %rdx
@@ -222,8 +220,6 @@ cmpxchg16b oword ptr [rax]
movzx %al, %rsi
movzx %ax, %esi
movzx %ax, %rsi
- movzx (%rax), %edx
- movzx (%rax), %rdx
movzx (%rax), %dx
movzb (%rax), %edx
movzb (%rax), %rdx
@@ -277,8 +273,6 @@ cmpxchg16b oword ptr [rax]
.att_syntax
movsx (%rax),%ax
-movsx (%rax),%eax
-movsx (%rax),%rax
movsxb (%rax), %dx
movsxb (%rax), %edx
movsxb (%rax), %rdx
@@ -287,8 +281,6 @@ movsxw (%rax), %rdx
movsxl (%rax), %rdx
movsxd (%rax),%rax
movzx (%rax),%ax
-movzx (%rax),%eax
-movzx (%rax),%rax
movzxb (%rax), %dx
movzxb (%rax), %edx
movzxb (%rax), %rdx
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -132,13 +132,9 @@ movswl, 2, 0xfbf, None, 2, Cpu386, Modrm
movsbq, 2, 0xfbe, None, 2, Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { Reg8|Byte|Unspecified|BaseIndex, Reg64 }
movswq, 2, 0xfbf, None, 2, Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { Reg16|Word|Unspecified|BaseIndex, Reg64 }
movslq, 2, 0x63, None, 1, Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { Reg32|Dword|Unspecified|BaseIndex, Reg64 }
-// Intel Syntax next 3 insns
-movsx, 2, 0xfbe, None, 2, Cpu386, Modrm|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|ATTSyntax, { Reg8|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
-movsx, 2, 0xfbf, None, 2, Cpu386, Modrm|No_bSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|ATTSyntax, { Reg16|Unspecified|BaseIndex, Reg32|Reg64 }
-movsx, 2, 0x63, None, 1, Cpu64, Modrm|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64|ATTSyntax, { Reg32|Unspecified|BaseIndex, Reg64 }
-movsx, 2, 0xfbe, None, 2, Cpu386, Modrm|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|IntelSyntax, { Reg8|Byte|BaseIndex, Reg16|Reg32|Reg64 }
-movsx, 2, 0xfbf, None, 2, Cpu386, Modrm|No_bSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|IntelSyntax, { Reg16|Word|BaseIndex, Reg32|Reg64 }
-movsx, 2, 0x63, None, 1, Cpu64, Modrm|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64|IntelSyntax, { Reg32|Dword|BaseIndex, Reg64 }
+// Intel Syntax next 2 insns
+movsx, 2, 0xfbe, None, 2, Cpu386, W|Modrm|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg8|Reg16|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
+movsx, 2, 0x63, None, 1, Cpu64, Modrm|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Unspecified|BaseIndex, Reg32|Reg64 }
movsxd, 2, 0x63, None, 1, Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Unspecified|BaseIndex, Reg32|Reg64 }
movsxd, 2, 0x63, None, 1, Cpu64, Amd64|Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Unspecified|BaseIndex, Reg16 }
movsxd, 2, 0x63, None, 1, Cpu64, Intel64|Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg16|Unspecified|BaseIndex, Reg16 }
@@ -146,12 +142,9 @@ movsxd, 2, 0x63, None, 1, Cpu64, Intel64
// Move with zero extend.
movzb, 2, 0xfb6, None, 2, Cpu386, Modrm|No_bSuf|No_sSuf|No_ldSuf, { Reg8|Byte|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
movzw, 2, 0xfb7, None, 2, Cpu386, Modrm|No_bSuf|No_wSuf|No_sSuf|No_ldSuf, { Reg16|Word|Unspecified|BaseIndex, Reg32|Reg64 }
-// Intel Syntax next 2 insns (the 64-bit variants are not particulary
+// Intel Syntax next insn (the 64-bit variant is not particulary
// useful since the zero extend 32->64 is implicit, but we can encode them).
-movzx, 2, 0xfb6, None, 2, Cpu386, Modrm|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|ATTSyntax, { Reg8|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
-movzx, 2, 0xfb7, None, 2, Cpu386, Modrm|No_bSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|ATTSyntax, { Reg16|Unspecified|BaseIndex, Reg32|Reg64 }
-movzx, 2, 0xfb6, None, 2, Cpu386, Modrm|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|IntelSyntax, { Reg8|Byte|BaseIndex, Reg16|Reg32|Reg64 }
-movzx, 2, 0xfb7, None, 2, Cpu386, Modrm|No_bSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|IntelSyntax, { Reg16|Word|BaseIndex, Reg32|Reg64 }
+movzx, 2, 0xfb6, None, 2, Cpu386, W|Modrm|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg8|Reg16|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
// Push instructions.
push, 1, 0x50, None, 1, CpuNo64, No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg16|Reg32 }
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
2020-02-14 12:26 ` [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous " Jan Beulich
@ 2020-02-14 12:28 ` H.J. Lu
2020-02-14 13:13 ` Jan Beulich
2020-02-14 13:54 ` Jan Beulich
0 siblings, 2 replies; 27+ messages in thread
From: H.J. Lu @ 2020-02-14 12:28 UTC (permalink / raw)
To: Jan Beulich; +Cc: binutils
On Fri, Feb 14, 2020 at 4:26 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> As pointed out in "x86: replace adhoc (partly wrong) ambiguous operand
> checking for MOVSX/MOVZX" silently guessing what the programmer may have
> meant is not helpful, the more that we don't do so elsewhere anymore
> (except in cases where it is overwhelmingly likely that the other case
> isn't meant, like here for it meant to be a "sign/zero extension" from
> 16 bits to 16 bits).
>
> gas/
> 2020-02-XX Jan Beulich <jbeulich@suse.com>
>
> PR gas/25438
> * config/tc-i386.c (process_suffix): Default movsx/movzx to byte
> suffix only when destination is a word reg.
> testsuite/gas/i386/noreg16.l, testsuite/gas/i386/noreg32.l,
> testsuite/gas/i386/noreg64.l: Adjust expectations.
No need for this since this is documented behavior of AT&T syntax.
--
H.J.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v8 1/2] x86: replace adhoc (partly wrong) ambiguous operand checking for MOVSX/MOVZX
2020-02-14 12:26 ` [PATCH v8 1/2] x86: replace adhoc (partly wrong) ambiguous operand checking " Jan Beulich
@ 2020-02-14 12:31 ` H.J. Lu
2020-02-14 12:34 ` H.J. Lu
1 sibling, 0 replies; 27+ messages in thread
From: H.J. Lu @ 2020-02-14 12:31 UTC (permalink / raw)
To: Jan Beulich; +Cc: binutils
On Fri, Feb 14, 2020 at 4:26 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> For these to get treatment consistent with other operand size checking
> the special logic shouldn't live in md_assemble(), but process_suffix().
> And there's more logic involved than simply zapping the suffix.
>
> Note however that MOVS[BW]* and MOVZ[BW]* still won't be fully
> consistent, due to the objection to fold MOVS* templates just like was
> done for MOVZ* in c07315e0c6 ("x86: allow suffix-less movzw and 64-bit
> movzb").
We can revisit this issue as so many things have changed in this area.
> Note further that it is against my own intentions to have MOVSX/MOVZX
> silently default to a byte source in AT&T mode. This should happen only
> when the desination register is a 16-bit one. In all other cases there
^^^^^^^^^^ Typo.
> is an ambiguity, and the user should be warned. But it was explicitly
> requested for this to be done in a way inconsistent with everything
> else.
>
> Note finally that the assembler change points out (and this patch fixes)
> a wrong Intel syntax test introduced by bc31405ebb2c ("x86-64: Properly
> encode and decode movsxd"): When source code specifies a 16-bit
> destination register, disassembly expectations shouldn't have been to
> find a 32-bit one.
>
> gas/
> 2020-02-XX Jan Beulich <jbeulich@suse.com>
>
> PR gas/25438
> * config/tc-i386.c (md_assemble): Move movsx/movzx special
> casing ...
> (process_suffix): ... here. Consider just the first operand
> initially.
> (check_long_reg): Drop opcode 0x63 special case again.
> * testsuite/gas/i386/i386.s, testsuite/gas/i386/iamcu-1.s,
> testsuite/gas/i386/ilp32/x86-64.s, testsuite/gas/i386/x86_64.s:
> Move ambiguous operand size tests ...
> * testsuite/gas/i386/noreg16.s, testsuite/gas/i386/noreg32.s,
> testsuite/gas/i386/noreg64.s: ... here.
> * testsuite/gas/i386/i386.d, testsuite/gas/i386/i386-intel.d
> testsuite/gas/i386/iamcu-1.d, testsuite/gas/i386/ilp32/x86-64.d,
> testsuite/gas/i386/k1om.d, testsuite/gas/i386/l1om.d,
> testsuite/gas/i386/movx16.l, testsuite/gas/i386/movx32.l,
> testsuite/gas/i386/movx64.l, testsuite/gas/i386/noreg16.d,
> testsuite/gas/i386/noreg32.d, testsuite/gas/i386/noreg64.d,
> testsuite/gas/i386/x86-64-movsxd.d,
> testsuite/gas/i386/x86-64-movsxd-intel.d,
> testsuite/gas/i386/x86_64.d, testsuite/gas/i386/x86_64-intel.d:
> Adjust expectations.
> * testsuite/gas/i386/movx16.s, testsuite/gas/i386/movx16.l,
> testsuite/gas/i386/movx32.s, testsuite/gas/i386/movx32.l,
> testsuite/gas/i386/movx64.s, testsuite/gas/i386/movx64.l: New.
> * testsuite/gas/i386/i386.exp: Run new tests.
>
> opcodes/
> 2020-02-XX Jan Beulich <jbeulich@suse.com>
>
> PR gas/25438
> * i386-opc.tbl (movsx): Fold patterns. Also allow Reg32 as
> destination for Cpu64-only variant.
> (movsxd): Also allow Reg32 as destination. Drop Rex64.
> (movzx): Fold patterns.
> * i386-tbl.h: Re-generate.
OK.
Thanks.
--
H.J.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v8 1/2] x86: replace adhoc (partly wrong) ambiguous operand checking for MOVSX/MOVZX
2020-02-14 12:26 ` [PATCH v8 1/2] x86: replace adhoc (partly wrong) ambiguous operand checking " Jan Beulich
2020-02-14 12:31 ` H.J. Lu
@ 2020-02-14 12:34 ` H.J. Lu
2020-02-14 12:42 ` Jan Beulich
1 sibling, 1 reply; 27+ messages in thread
From: H.J. Lu @ 2020-02-14 12:34 UTC (permalink / raw)
To: Jan Beulich; +Cc: binutils
On Fri, Feb 14, 2020 at 4:26 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> For these to get treatment consistent with other operand size checking
> the special logic shouldn't live in md_assemble(), but process_suffix().
> And there's more logic involved than simply zapping the suffix.
>
> Note however that MOVS[BW]* and MOVZ[BW]* still won't be fully
> consistent, due to the objection to fold MOVS* templates just like was
> done for MOVZ* in c07315e0c6 ("x86: allow suffix-less movzw and 64-bit
> movzb").
>
> Note further that it is against my own intentions to have MOVSX/MOVZX
> silently default to a byte source in AT&T mode. This should happen only
> when the desination register is a 16-bit one. In all other cases there
> is an ambiguity, and the user should be warned. But it was explicitly
> requested for this to be done in a way inconsistent with everything
> else.
>
> Note finally that the assembler change points out (and this patch fixes)
> a wrong Intel syntax test introduced by bc31405ebb2c ("x86-64: Properly
> encode and decode movsxd"): When source code specifies a 16-bit
> destination register, disassembly expectations shouldn't have been to
> find a 32-bit one.
>
> gas/
> 2020-02-XX Jan Beulich <jbeulich@suse.com>
>
> PR gas/25438
> * config/tc-i386.c (md_assemble): Move movsx/movzx special
> casing ...
> (process_suffix): ... here. Consider just the first operand
> initially.
> (check_long_reg): Drop opcode 0x63 special case again.
> * testsuite/gas/i386/i386.s, testsuite/gas/i386/iamcu-1.s,
> testsuite/gas/i386/ilp32/x86-64.s, testsuite/gas/i386/x86_64.s:
> Move ambiguous operand size tests ...
> * testsuite/gas/i386/noreg16.s, testsuite/gas/i386/noreg32.s,
> testsuite/gas/i386/noreg64.s: ... here.
> * testsuite/gas/i386/i386.d, testsuite/gas/i386/i386-intel.d
> testsuite/gas/i386/iamcu-1.d, testsuite/gas/i386/ilp32/x86-64.d,
> testsuite/gas/i386/k1om.d, testsuite/gas/i386/l1om.d,
> testsuite/gas/i386/movx16.l, testsuite/gas/i386/movx32.l,
> testsuite/gas/i386/movx64.l, testsuite/gas/i386/noreg16.d,
> testsuite/gas/i386/noreg32.d, testsuite/gas/i386/noreg64.d,
> testsuite/gas/i386/x86-64-movsxd.d,
> testsuite/gas/i386/x86-64-movsxd-intel.d,
> testsuite/gas/i386/x86_64.d, testsuite/gas/i386/x86_64-intel.d:
> Adjust expectations.
> * testsuite/gas/i386/movx16.s, testsuite/gas/i386/movx16.l,
> testsuite/gas/i386/movx32.s, testsuite/gas/i386/movx32.l,
> testsuite/gas/i386/movx64.s, testsuite/gas/i386/movx64.l: New.
> * testsuite/gas/i386/i386.exp: Run new tests.
>
> opcodes/
> 2020-02-XX Jan Beulich <jbeulich@suse.com>
>
> PR gas/25438
> * i386-opc.tbl (movsx): Fold patterns. Also allow Reg32 as
> destination for Cpu64-only variant.
> (movsxd): Also allow Reg32 as destination. Drop Rex64.
> (movzx): Fold patterns.
> * i386-tbl.h: Re-generate.
> ---
> v8: Silently default movsx/movsx to byte source in AT&T mode
> irrespective of destination register size.
> v7: Merge with previously separate patch introducing new testcases.
> v6: Move to end of series.
> v5: Re-base.
> v4: Re-base.
> v3: Re-base.
> v2: Undo No_lSuf addition to MOVSXD template. Drop bogus / pointless
> !i.tm.opcode_modifier.rex64 part of conditional in md_assemble().
> Re-base over changes earlier in the series.
>
> --- a/opcodes/i386-opc.tbl
> +++ b/opcodes/i386-opc.tbl
> @@ -132,13 +132,9 @@ movswl, 2, 0xfbf, None, 2, Cpu386, Modrm
> movsbq, 2, 0xfbe, None, 2, Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { Reg8|Byte|Unspecified|BaseIndex, Reg64 }
> movswq, 2, 0xfbf, None, 2, Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { Reg16|Word|Unspecified|BaseIndex, Reg64 }
> movslq, 2, 0x63, None, 1, Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { Reg32|Dword|Unspecified|BaseIndex, Reg64 }
> -// Intel Syntax next 3 insns
> -movsx, 2, 0xfbe, None, 2, Cpu386, Modrm|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|ATTSyntax, { Reg8|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
> -movsx, 2, 0xfbf, None, 2, Cpu386, Modrm|No_bSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|ATTSyntax, { Reg16|Unspecified|BaseIndex, Reg32|Reg64 }
> -movsx, 2, 0x63, None, 1, Cpu64, Modrm|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64|ATTSyntax, { Reg32|Unspecified|BaseIndex, Reg64 }
> -movsx, 2, 0xfbe, None, 2, Cpu386, Modrm|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|IntelSyntax, { Reg8|Byte|BaseIndex, Reg16|Reg32|Reg64 }
> -movsx, 2, 0xfbf, None, 2, Cpu386, Modrm|No_bSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|IntelSyntax, { Reg16|Word|BaseIndex, Reg32|Reg64 }
> -movsx, 2, 0x63, None, 1, Cpu64, Modrm|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64|IntelSyntax, { Reg32|Dword|BaseIndex, Reg64 }
> +// Intel Syntax next 2 insns
^^^^^^^^^^^^^^^^ Is this comment correct?
> +movsx, 2, 0xfbe, None, 2, Cpu386, W|Modrm|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg8|Reg16|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
> +movsx, 2, 0x63, None, 1, Cpu64, Modrm|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Unspecified|BaseIndex, Reg32|Reg64 }
> movsxd, 2, 0x63, None, 1, Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Unspecified|BaseIndex, Reg32|Reg64 }
> movsxd, 2, 0x63, None, 1, Cpu64, Amd64|Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Unspecified|BaseIndex, Reg16 }
> movsxd, 2, 0x63, None, 1, Cpu64, Intel64|Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg16|Unspecified|BaseIndex, Reg16 }
> @@ -146,12 +142,9 @@ movsxd, 2, 0x63, None, 1, Cpu64, Intel64
> // Move with zero extend.
> movzb, 2, 0xfb6, None, 2, Cpu386, Modrm|No_bSuf|No_sSuf|No_ldSuf, { Reg8|Byte|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
> movzw, 2, 0xfb7, None, 2, Cpu386, Modrm|No_bSuf|No_wSuf|No_sSuf|No_ldSuf, { Reg16|Word|Unspecified|BaseIndex, Reg32|Reg64 }
> -// Intel Syntax next 2 insns (the 64-bit variants are not particulary
> +// Intel Syntax next insn (the 64-bit variant is not particulary
^^^^^^^^^^^^^^^^ Is this comment correct?
> // useful since the zero extend 32->64 is implicit, but we can encode them).
> -movzx, 2, 0xfb6, None, 2, Cpu386, Modrm|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|ATTSyntax, { Reg8|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
> -movzx, 2, 0xfb7, None, 2, Cpu386, Modrm|No_bSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|ATTSyntax, { Reg16|Unspecified|BaseIndex, Reg32|Reg64 }
> -movzx, 2, 0xfb6, None, 2, Cpu386, Modrm|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|IntelSyntax, { Reg8|Byte|BaseIndex, Reg16|Reg32|Reg64 }
> -movzx, 2, 0xfb7, None, 2, Cpu386, Modrm|No_bSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|IntelSyntax, { Reg16|Word|BaseIndex, Reg32|Reg64 }
> +movzx, 2, 0xfb6, None, 2, Cpu386, W|Modrm|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg8|Reg16|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
>
> // Push instructions.
> push, 1, 0x50, None, 1, CpuNo64, No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg16|Reg32 }
>
--
H.J.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v8 1/2] x86: replace adhoc (partly wrong) ambiguous operand checking for MOVSX/MOVZX
2020-02-14 12:34 ` H.J. Lu
@ 2020-02-14 12:42 ` Jan Beulich
2020-02-14 12:49 ` H.J. Lu
0 siblings, 1 reply; 27+ messages in thread
From: Jan Beulich @ 2020-02-14 12:42 UTC (permalink / raw)
To: H.J. Lu; +Cc: binutils
On 14.02.2020 13:34, H.J. Lu wrote:
> On Fri, Feb 14, 2020 at 4:26 AM Jan Beulich <jbeulich@suse.com> wrote:
>> --- a/opcodes/i386-opc.tbl
>> +++ b/opcodes/i386-opc.tbl
>> @@ -132,13 +132,9 @@ movswl, 2, 0xfbf, None, 2, Cpu386, Modrm
>> movsbq, 2, 0xfbe, None, 2, Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { Reg8|Byte|Unspecified|BaseIndex, Reg64 }
>> movswq, 2, 0xfbf, None, 2, Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { Reg16|Word|Unspecified|BaseIndex, Reg64 }
>> movslq, 2, 0x63, None, 1, Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { Reg32|Dword|Unspecified|BaseIndex, Reg64 }
>> -// Intel Syntax next 3 insns
>> -movsx, 2, 0xfbe, None, 2, Cpu386, Modrm|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|ATTSyntax, { Reg8|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
>> -movsx, 2, 0xfbf, None, 2, Cpu386, Modrm|No_bSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|ATTSyntax, { Reg16|Unspecified|BaseIndex, Reg32|Reg64 }
>> -movsx, 2, 0x63, None, 1, Cpu64, Modrm|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64|ATTSyntax, { Reg32|Unspecified|BaseIndex, Reg64 }
>> -movsx, 2, 0xfbe, None, 2, Cpu386, Modrm|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|IntelSyntax, { Reg8|Byte|BaseIndex, Reg16|Reg32|Reg64 }
>> -movsx, 2, 0xfbf, None, 2, Cpu386, Modrm|No_bSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|IntelSyntax, { Reg16|Word|BaseIndex, Reg32|Reg64 }
>> -movsx, 2, 0x63, None, 1, Cpu64, Modrm|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64|IntelSyntax, { Reg32|Dword|BaseIndex, Reg64 }
>> +// Intel Syntax next 2 insns
> ^^^^^^^^^^^^^^^^ Is this comment correct?
Yes. MOVSX isn't AT&T syntax, it's just that we permit it to be used
there too (because people actually use it, albeit strictly speaking in
error).
>> +movsx, 2, 0xfbe, None, 2, Cpu386, W|Modrm|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg8|Reg16|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
>> +movsx, 2, 0x63, None, 1, Cpu64, Modrm|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Unspecified|BaseIndex, Reg32|Reg64 }
>> movsxd, 2, 0x63, None, 1, Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Unspecified|BaseIndex, Reg32|Reg64 }
>> movsxd, 2, 0x63, None, 1, Cpu64, Amd64|Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Unspecified|BaseIndex, Reg16 }
>> movsxd, 2, 0x63, None, 1, Cpu64, Intel64|Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg16|Unspecified|BaseIndex, Reg16 }
>> @@ -146,12 +142,9 @@ movsxd, 2, 0x63, None, 1, Cpu64, Intel64
>> // Move with zero extend.
>> movzb, 2, 0xfb6, None, 2, Cpu386, Modrm|No_bSuf|No_sSuf|No_ldSuf, { Reg8|Byte|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
>> movzw, 2, 0xfb7, None, 2, Cpu386, Modrm|No_bSuf|No_wSuf|No_sSuf|No_ldSuf, { Reg16|Word|Unspecified|BaseIndex, Reg32|Reg64 }
>> -// Intel Syntax next 2 insns (the 64-bit variants are not particulary
>> +// Intel Syntax next insn (the 64-bit variant is not particulary
> ^^^^^^^^^^^^^^^^ Is this comment correct?
Same for MOVZX.
Jan
>> // useful since the zero extend 32->64 is implicit, but we can encode them).
>> -movzx, 2, 0xfb6, None, 2, Cpu386, Modrm|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|ATTSyntax, { Reg8|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
>> -movzx, 2, 0xfb7, None, 2, Cpu386, Modrm|No_bSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|ATTSyntax, { Reg16|Unspecified|BaseIndex, Reg32|Reg64 }
>> -movzx, 2, 0xfb6, None, 2, Cpu386, Modrm|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|IntelSyntax, { Reg8|Byte|BaseIndex, Reg16|Reg32|Reg64 }
>> -movzx, 2, 0xfb7, None, 2, Cpu386, Modrm|No_bSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|IntelSyntax, { Reg16|Word|BaseIndex, Reg32|Reg64 }
>> +movzx, 2, 0xfb6, None, 2, Cpu386, W|Modrm|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg8|Reg16|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
>>
>> // Push instructions.
>> push, 1, 0x50, None, 1, CpuNo64, No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg16|Reg32 }
>>
>
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v8 1/2] x86: replace adhoc (partly wrong) ambiguous operand checking for MOVSX/MOVZX
2020-02-14 12:42 ` Jan Beulich
@ 2020-02-14 12:49 ` H.J. Lu
0 siblings, 0 replies; 27+ messages in thread
From: H.J. Lu @ 2020-02-14 12:49 UTC (permalink / raw)
To: Jan Beulich; +Cc: binutils
On Fri, Feb 14, 2020 at 4:42 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 14.02.2020 13:34, H.J. Lu wrote:
> > On Fri, Feb 14, 2020 at 4:26 AM Jan Beulich <jbeulich@suse.com> wrote:
> >> --- a/opcodes/i386-opc.tbl
> >> +++ b/opcodes/i386-opc.tbl
> >> @@ -132,13 +132,9 @@ movswl, 2, 0xfbf, None, 2, Cpu386, Modrm
> >> movsbq, 2, 0xfbe, None, 2, Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { Reg8|Byte|Unspecified|BaseIndex, Reg64 }
> >> movswq, 2, 0xfbf, None, 2, Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { Reg16|Word|Unspecified|BaseIndex, Reg64 }
> >> movslq, 2, 0x63, None, 1, Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64, { Reg32|Dword|Unspecified|BaseIndex, Reg64 }
> >> -// Intel Syntax next 3 insns
> >> -movsx, 2, 0xfbe, None, 2, Cpu386, Modrm|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|ATTSyntax, { Reg8|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
> >> -movsx, 2, 0xfbf, None, 2, Cpu386, Modrm|No_bSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|ATTSyntax, { Reg16|Unspecified|BaseIndex, Reg32|Reg64 }
> >> -movsx, 2, 0x63, None, 1, Cpu64, Modrm|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64|ATTSyntax, { Reg32|Unspecified|BaseIndex, Reg64 }
> >> -movsx, 2, 0xfbe, None, 2, Cpu386, Modrm|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|IntelSyntax, { Reg8|Byte|BaseIndex, Reg16|Reg32|Reg64 }
> >> -movsx, 2, 0xfbf, None, 2, Cpu386, Modrm|No_bSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|IntelSyntax, { Reg16|Word|BaseIndex, Reg32|Reg64 }
> >> -movsx, 2, 0x63, None, 1, Cpu64, Modrm|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf|Rex64|IntelSyntax, { Reg32|Dword|BaseIndex, Reg64 }
> >> +// Intel Syntax next 2 insns
> > ^^^^^^^^^^^^^^^^ Is this comment correct?
>
> Yes. MOVSX isn't AT&T syntax, it's just that we permit it to be used
> there too (because people actually use it, albeit strictly speaking in
> error).
I am checking in a patch to document different mnemonics of movsx,
movsxd and movzx in AT&T syntax:
https://sourceware.org/ml/binutils/2020-02/msg00332.html
> >> +movsx, 2, 0xfbe, None, 2, Cpu386, W|Modrm|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg8|Reg16|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
> >> +movsx, 2, 0x63, None, 1, Cpu64, Modrm|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Unspecified|BaseIndex, Reg32|Reg64 }
> >> movsxd, 2, 0x63, None, 1, Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Unspecified|BaseIndex, Reg32|Reg64 }
> >> movsxd, 2, 0x63, None, 1, Cpu64, Amd64|Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Unspecified|BaseIndex, Reg16 }
> >> movsxd, 2, 0x63, None, 1, Cpu64, Intel64|Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg16|Unspecified|BaseIndex, Reg16 }
> >> @@ -146,12 +142,9 @@ movsxd, 2, 0x63, None, 1, Cpu64, Intel64
> >> // Move with zero extend.
> >> movzb, 2, 0xfb6, None, 2, Cpu386, Modrm|No_bSuf|No_sSuf|No_ldSuf, { Reg8|Byte|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
> >> movzw, 2, 0xfb7, None, 2, Cpu386, Modrm|No_bSuf|No_wSuf|No_sSuf|No_ldSuf, { Reg16|Word|Unspecified|BaseIndex, Reg32|Reg64 }
> >> -// Intel Syntax next 2 insns (the 64-bit variants are not particulary
> >> +// Intel Syntax next insn (the 64-bit variant is not particulary
> > ^^^^^^^^^^^^^^^^ Is this comment correct?
>
> Same for MOVZX.
>
--
H.J.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
2020-02-14 12:28 ` H.J. Lu
@ 2020-02-14 13:13 ` Jan Beulich
2020-02-14 13:54 ` Jan Beulich
1 sibling, 0 replies; 27+ messages in thread
From: Jan Beulich @ 2020-02-14 13:13 UTC (permalink / raw)
To: H.J. Lu; +Cc: binutils
On 14.02.2020 13:28, H.J. Lu wrote:
> On Fri, Feb 14, 2020 at 4:26 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> As pointed out in "x86: replace adhoc (partly wrong) ambiguous operand
>> checking for MOVSX/MOVZX" silently guessing what the programmer may have
>> meant is not helpful, the more that we don't do so elsewhere anymore
>> (except in cases where it is overwhelmingly likely that the other case
>> isn't meant, like here for it meant to be a "sign/zero extension" from
>> 16 bits to 16 bits).
>>
>> gas/
>> 2020-02-XX Jan Beulich <jbeulich@suse.com>
>>
>> PR gas/25438
>> * config/tc-i386.c (process_suffix): Default movsx/movzx to byte
>> suffix only when destination is a word reg.
>> testsuite/gas/i386/noreg16.l, testsuite/gas/i386/noreg32.l,
>> testsuite/gas/i386/noreg64.l: Adjust expectations.
>
> No need for this since this is documented behavior of AT&T syntax.
Well, you know eagerly how people usually look at documentation.
There being an ambiguity still deserves a warning. Documentation
tells us what code to generate (and that we may not change this).
Anyway - I give up here and will maintain the patch in my
private trees. Hopefully there'll be a better time for it later
on.
Jan
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
2020-02-14 12:28 ` H.J. Lu
2020-02-14 13:13 ` Jan Beulich
@ 2020-02-14 13:54 ` Jan Beulich
2020-02-14 14:16 ` H.J. Lu
1 sibling, 1 reply; 27+ messages in thread
From: Jan Beulich @ 2020-02-14 13:54 UTC (permalink / raw)
To: H.J. Lu; +Cc: binutils
On 14.02.2020 13:28, H.J. Lu wrote:
> On Fri, Feb 14, 2020 at 4:26 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> As pointed out in "x86: replace adhoc (partly wrong) ambiguous operand
>> checking for MOVSX/MOVZX" silently guessing what the programmer may have
>> meant is not helpful, the more that we don't do so elsewhere anymore
>> (except in cases where it is overwhelmingly likely that the other case
>> isn't meant, like here for it meant to be a "sign/zero extension" from
>> 16 bits to 16 bits).
>>
>> gas/
>> 2020-02-XX Jan Beulich <jbeulich@suse.com>
>>
>> PR gas/25438
>> * config/tc-i386.c (process_suffix): Default movsx/movzx to byte
>> suffix only when destination is a word reg.
>> testsuite/gas/i386/noreg16.l, testsuite/gas/i386/noreg32.l,
>> testsuite/gas/i386/noreg64.l: Adjust expectations.
>
> No need for this since this is documented behavior of AT&T syntax.
I've just looked at the documentation again: As said in the
other reply to your doc change, these mnemonics aren't
mentioned as legal in Solaris'es AT&T spec. And I also
can't find gas doc saying so. Would you please point me at
where this is being documented?
Jan
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
2020-02-14 13:54 ` Jan Beulich
@ 2020-02-14 14:16 ` H.J. Lu
2020-02-14 14:23 ` Jan Beulich
0 siblings, 1 reply; 27+ messages in thread
From: H.J. Lu @ 2020-02-14 14:16 UTC (permalink / raw)
To: Jan Beulich; +Cc: binutils
On Fri, Feb 14, 2020 at 5:54 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 14.02.2020 13:28, H.J. Lu wrote:
> > On Fri, Feb 14, 2020 at 4:26 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> As pointed out in "x86: replace adhoc (partly wrong) ambiguous operand
> >> checking for MOVSX/MOVZX" silently guessing what the programmer may have
> >> meant is not helpful, the more that we don't do so elsewhere anymore
> >> (except in cases where it is overwhelmingly likely that the other case
> >> isn't meant, like here for it meant to be a "sign/zero extension" from
> >> 16 bits to 16 bits).
> >>
> >> gas/
> >> 2020-02-XX Jan Beulich <jbeulich@suse.com>
> >>
> >> PR gas/25438
> >> * config/tc-i386.c (process_suffix): Default movsx/movzx to byte
> >> suffix only when destination is a word reg.
> >> testsuite/gas/i386/noreg16.l, testsuite/gas/i386/noreg32.l,
> >> testsuite/gas/i386/noreg64.l: Adjust expectations.
> >
> > No need for this since this is documented behavior of AT&T syntax.
>
> I've just looked at the documentation again: As said in the
> other reply to your doc change, these mnemonics aren't
> mentioned as legal in Solaris'es AT&T spec. And I also
> can't find gas doc saying so. Would you please point me at
> where this is being documented?
Solaris spec doesn't mention movsx[bwl] nor movsx.
--
H.J.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
2020-02-14 14:16 ` H.J. Lu
@ 2020-02-14 14:23 ` Jan Beulich
2020-02-14 14:26 ` H.J. Lu
0 siblings, 1 reply; 27+ messages in thread
From: Jan Beulich @ 2020-02-14 14:23 UTC (permalink / raw)
To: H.J. Lu; +Cc: binutils
On 14.02.2020 15:16, H.J. Lu wrote:
> On Fri, Feb 14, 2020 at 5:54 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 14.02.2020 13:28, H.J. Lu wrote:
>>> On Fri, Feb 14, 2020 at 4:26 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> As pointed out in "x86: replace adhoc (partly wrong) ambiguous operand
>>>> checking for MOVSX/MOVZX" silently guessing what the programmer may have
>>>> meant is not helpful, the more that we don't do so elsewhere anymore
>>>> (except in cases where it is overwhelmingly likely that the other case
>>>> isn't meant, like here for it meant to be a "sign/zero extension" from
>>>> 16 bits to 16 bits).
>>>>
>>>> gas/
>>>> 2020-02-XX Jan Beulich <jbeulich@suse.com>
>>>>
>>>> PR gas/25438
>>>> * config/tc-i386.c (process_suffix): Default movsx/movzx to byte
>>>> suffix only when destination is a word reg.
>>>> testsuite/gas/i386/noreg16.l, testsuite/gas/i386/noreg32.l,
>>>> testsuite/gas/i386/noreg64.l: Adjust expectations.
>>>
>>> No need for this since this is documented behavior of AT&T syntax.
>>
>> I've just looked at the documentation again: As said in the
>> other reply to your doc change, these mnemonics aren't
>> mentioned as legal in Solaris'es AT&T spec. And I also
>> can't find gas doc saying so. Would you please point me at
>> where this is being documented?
>
> Solaris spec doesn't mention movsx[bwl] nor movsx.
Right, so where did you take from that "this is documented behavior"?
Jan
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
2020-02-14 14:23 ` Jan Beulich
@ 2020-02-14 14:26 ` H.J. Lu
2020-02-14 14:32 ` Jan Beulich
0 siblings, 1 reply; 27+ messages in thread
From: H.J. Lu @ 2020-02-14 14:26 UTC (permalink / raw)
To: Jan Beulich; +Cc: binutils
On Fri, Feb 14, 2020 at 6:23 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 14.02.2020 15:16, H.J. Lu wrote:
> > On Fri, Feb 14, 2020 at 5:54 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 14.02.2020 13:28, H.J. Lu wrote:
> >>> On Fri, Feb 14, 2020 at 4:26 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> As pointed out in "x86: replace adhoc (partly wrong) ambiguous operand
> >>>> checking for MOVSX/MOVZX" silently guessing what the programmer may have
> >>>> meant is not helpful, the more that we don't do so elsewhere anymore
> >>>> (except in cases where it is overwhelmingly likely that the other case
> >>>> isn't meant, like here for it meant to be a "sign/zero extension" from
> >>>> 16 bits to 16 bits).
> >>>>
> >>>> gas/
> >>>> 2020-02-XX Jan Beulich <jbeulich@suse.com>
> >>>>
> >>>> PR gas/25438
> >>>> * config/tc-i386.c (process_suffix): Default movsx/movzx to byte
> >>>> suffix only when destination is a word reg.
> >>>> testsuite/gas/i386/noreg16.l, testsuite/gas/i386/noreg32.l,
> >>>> testsuite/gas/i386/noreg64.l: Adjust expectations.
> >>>
> >>> No need for this since this is documented behavior of AT&T syntax.
> >>
> >> I've just looked at the documentation again: As said in the
> >> other reply to your doc change, these mnemonics aren't
> >> mentioned as legal in Solaris'es AT&T spec. And I also
> >> can't find gas doc saying so. Would you please point me at
> >> where this is being documented?
> >
> > Solaris spec doesn't mention movsx[bwl] nor movsx.
>
> Right, so where did you take from that "this is documented behavior"?
>
Documented in gas manual.
--
H.J.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
2020-02-14 14:26 ` H.J. Lu
@ 2020-02-14 14:32 ` Jan Beulich
2020-02-14 14:38 ` H.J. Lu
0 siblings, 1 reply; 27+ messages in thread
From: Jan Beulich @ 2020-02-14 14:32 UTC (permalink / raw)
To: H.J. Lu; +Cc: binutils
On 14.02.2020 15:25, H.J. Lu wrote:
> On Fri, Feb 14, 2020 at 6:23 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 14.02.2020 15:16, H.J. Lu wrote:
>>> On Fri, Feb 14, 2020 at 5:54 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 14.02.2020 13:28, H.J. Lu wrote:
>>>>> On Fri, Feb 14, 2020 at 4:26 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>
>>>>>> As pointed out in "x86: replace adhoc (partly wrong) ambiguous operand
>>>>>> checking for MOVSX/MOVZX" silently guessing what the programmer may have
>>>>>> meant is not helpful, the more that we don't do so elsewhere anymore
>>>>>> (except in cases where it is overwhelmingly likely that the other case
>>>>>> isn't meant, like here for it meant to be a "sign/zero extension" from
>>>>>> 16 bits to 16 bits).
>>>>>>
>>>>>> gas/
>>>>>> 2020-02-XX Jan Beulich <jbeulich@suse.com>
>>>>>>
>>>>>> PR gas/25438
>>>>>> * config/tc-i386.c (process_suffix): Default movsx/movzx to byte
>>>>>> suffix only when destination is a word reg.
>>>>>> testsuite/gas/i386/noreg16.l, testsuite/gas/i386/noreg32.l,
>>>>>> testsuite/gas/i386/noreg64.l: Adjust expectations.
>>>>>
>>>>> No need for this since this is documented behavior of AT&T syntax.
>>>>
>>>> I've just looked at the documentation again: As said in the
>>>> other reply to your doc change, these mnemonics aren't
>>>> mentioned as legal in Solaris'es AT&T spec. And I also
>>>> can't find gas doc saying so. Would you please point me at
>>>> where this is being documented?
>>>
>>> Solaris spec doesn't mention movsx[bwl] nor movsx.
>>
>> Right, so where did you take from that "this is documented behavior"?
>>
>
> Documented in gas manual.
Where? As said, I did look there without finding anything to this effect.
Also even if it was mentioned there, compatibility considerations then
still call for there being a warning. People moving code from other
assemblers may otherwise be caught by surprise.
Jan
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
2020-02-14 14:32 ` Jan Beulich
@ 2020-02-14 14:38 ` H.J. Lu
2020-02-14 15:47 ` Jan Beulich
2020-02-14 15:52 ` Jan Beulich
0 siblings, 2 replies; 27+ messages in thread
From: H.J. Lu @ 2020-02-14 14:38 UTC (permalink / raw)
To: Jan Beulich; +Cc: binutils
On Fri, Feb 14, 2020 at 6:32 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 14.02.2020 15:25, H.J. Lu wrote:
> > On Fri, Feb 14, 2020 at 6:23 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 14.02.2020 15:16, H.J. Lu wrote:
> >>> On Fri, Feb 14, 2020 at 5:54 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> On 14.02.2020 13:28, H.J. Lu wrote:
> >>>>> On Fri, Feb 14, 2020 at 4:26 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>
> >>>>>> As pointed out in "x86: replace adhoc (partly wrong) ambiguous operand
> >>>>>> checking for MOVSX/MOVZX" silently guessing what the programmer may have
> >>>>>> meant is not helpful, the more that we don't do so elsewhere anymore
> >>>>>> (except in cases where it is overwhelmingly likely that the other case
> >>>>>> isn't meant, like here for it meant to be a "sign/zero extension" from
> >>>>>> 16 bits to 16 bits).
> >>>>>>
> >>>>>> gas/
> >>>>>> 2020-02-XX Jan Beulich <jbeulich@suse.com>
> >>>>>>
> >>>>>> PR gas/25438
> >>>>>> * config/tc-i386.c (process_suffix): Default movsx/movzx to byte
> >>>>>> suffix only when destination is a word reg.
> >>>>>> testsuite/gas/i386/noreg16.l, testsuite/gas/i386/noreg32.l,
> >>>>>> testsuite/gas/i386/noreg64.l: Adjust expectations.
> >>>>>
> >>>>> No need for this since this is documented behavior of AT&T syntax.
> >>>>
> >>>> I've just looked at the documentation again: As said in the
> >>>> other reply to your doc change, these mnemonics aren't
> >>>> mentioned as legal in Solaris'es AT&T spec. And I also
> >>>> can't find gas doc saying so. Would you please point me at
> >>>> where this is being documented?
> >>>
> >>> Solaris spec doesn't mention movsx[bwl] nor movsx.
> >>
> >> Right, so where did you take from that "this is documented behavior"?
> >>
> >
> > Documented in gas manual.
>
> Where? As said, I did look there without finding anything to this effect.
It is there now.
> Also even if it was mentioned there, compatibility considerations then
> still call for there being a warning. People moving code from other
> assemblers may otherwise be caught by surprise.
Do these mnemonics have different encodings by other assemblers?
--
H.J.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
2020-02-14 14:38 ` H.J. Lu
@ 2020-02-14 15:47 ` Jan Beulich
2020-02-14 15:52 ` Jan Beulich
1 sibling, 0 replies; 27+ messages in thread
From: Jan Beulich @ 2020-02-14 15:47 UTC (permalink / raw)
To: H.J. Lu; +Cc: binutils
On 14.02.2020 15:37, H.J. Lu wrote:
> On Fri, Feb 14, 2020 at 6:32 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 14.02.2020 15:25, H.J. Lu wrote:
>>> On Fri, Feb 14, 2020 at 6:23 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 14.02.2020 15:16, H.J. Lu wrote:
>>>>> On Fri, Feb 14, 2020 at 5:54 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>
>>>>>> On 14.02.2020 13:28, H.J. Lu wrote:
>>>>>>> On Fri, Feb 14, 2020 at 4:26 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>
>>>>>>>> As pointed out in "x86: replace adhoc (partly wrong) ambiguous operand
>>>>>>>> checking for MOVSX/MOVZX" silently guessing what the programmer may have
>>>>>>>> meant is not helpful, the more that we don't do so elsewhere anymore
>>>>>>>> (except in cases where it is overwhelmingly likely that the other case
>>>>>>>> isn't meant, like here for it meant to be a "sign/zero extension" from
>>>>>>>> 16 bits to 16 bits).
>>>>>>>>
>>>>>>>> gas/
>>>>>>>> 2020-02-XX Jan Beulich <jbeulich@suse.com>
>>>>>>>>
>>>>>>>> PR gas/25438
>>>>>>>> * config/tc-i386.c (process_suffix): Default movsx/movzx to byte
>>>>>>>> suffix only when destination is a word reg.
>>>>>>>> testsuite/gas/i386/noreg16.l, testsuite/gas/i386/noreg32.l,
>>>>>>>> testsuite/gas/i386/noreg64.l: Adjust expectations.
>>>>>>>
>>>>>>> No need for this since this is documented behavior of AT&T syntax.
>>>>>>
>>>>>> I've just looked at the documentation again: As said in the
>>>>>> other reply to your doc change, these mnemonics aren't
>>>>>> mentioned as legal in Solaris'es AT&T spec. And I also
>>>>>> can't find gas doc saying so. Would you please point me at
>>>>>> where this is being documented?
>>>>>
>>>>> Solaris spec doesn't mention movsx[bwl] nor movsx.
>>>>
>>>> Right, so where did you take from that "this is documented behavior"?
>>>>
>>>
>>> Documented in gas manual.
>>
>> Where? As said, I did look there without finding anything to this effect.
>
> It is there now.
Okay, just to let this stand out: You've blocked my code change
on the basis of documentation that wasn't actually there. Why
do you think _any_ existing piece of code was written based on
the documentation you've added just now?
>> Also even if it was mentioned there, compatibility considerations then
>> still call for there being a warning. People moving code from other
>> assemblers may otherwise be caught by surprise.
>
> Do these mnemonics have different encodings by other assemblers?
How do I know? It's the nature of ambiguities that implementations
may make different choices. Hence the need to make the user aware.
Jan
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
2020-02-14 14:38 ` H.J. Lu
2020-02-14 15:47 ` Jan Beulich
@ 2020-02-14 15:52 ` Jan Beulich
2020-02-14 16:26 ` H.J. Lu
1 sibling, 1 reply; 27+ messages in thread
From: Jan Beulich @ 2020-02-14 15:52 UTC (permalink / raw)
To: H.J. Lu; +Cc: binutils
On 14.02.2020 15:37, H.J. Lu wrote:
> On Fri, Feb 14, 2020 at 6:32 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 14.02.2020 15:25, H.J. Lu wrote:
>>> On Fri, Feb 14, 2020 at 6:23 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 14.02.2020 15:16, H.J. Lu wrote:
>>>>> On Fri, Feb 14, 2020 at 5:54 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>
>>>>>> On 14.02.2020 13:28, H.J. Lu wrote:
>>>>>>> On Fri, Feb 14, 2020 at 4:26 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>
>>>>>>>> As pointed out in "x86: replace adhoc (partly wrong) ambiguous operand
>>>>>>>> checking for MOVSX/MOVZX" silently guessing what the programmer may have
>>>>>>>> meant is not helpful, the more that we don't do so elsewhere anymore
>>>>>>>> (except in cases where it is overwhelmingly likely that the other case
>>>>>>>> isn't meant, like here for it meant to be a "sign/zero extension" from
>>>>>>>> 16 bits to 16 bits).
>>>>>>>>
>>>>>>>> gas/
>>>>>>>> 2020-02-XX Jan Beulich <jbeulich@suse.com>
>>>>>>>>
>>>>>>>> PR gas/25438
>>>>>>>> * config/tc-i386.c (process_suffix): Default movsx/movzx to byte
>>>>>>>> suffix only when destination is a word reg.
>>>>>>>> testsuite/gas/i386/noreg16.l, testsuite/gas/i386/noreg32.l,
>>>>>>>> testsuite/gas/i386/noreg64.l: Adjust expectations.
>>>>>>>
>>>>>>> No need for this since this is documented behavior of AT&T syntax.
>>>>>>
>>>>>> I've just looked at the documentation again: As said in the
>>>>>> other reply to your doc change, these mnemonics aren't
>>>>>> mentioned as legal in Solaris'es AT&T spec. And I also
>>>>>> can't find gas doc saying so. Would you please point me at
>>>>>> where this is being documented?
>>>>>
>>>>> Solaris spec doesn't mention movsx[bwl] nor movsx.
>>>>
>>>> Right, so where did you take from that "this is documented behavior"?
>>>>
>>>
>>> Documented in gas manual.
>>
>> Where? As said, I did look there without finding anything to this effect.
>
> It is there now.
Hmm, even worse: It's not there. Neither of the two doc changes of
yours today say anything like this. Did you forget to both post a
patch _and_ push it, or am I blind, or are you simply lying to me?
I'm sorry for being blunt, but I'm getting really annoyed.
Jan
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
2020-02-14 15:52 ` Jan Beulich
@ 2020-02-14 16:26 ` H.J. Lu
2020-02-14 16:36 ` Jan Beulich
0 siblings, 1 reply; 27+ messages in thread
From: H.J. Lu @ 2020-02-14 16:26 UTC (permalink / raw)
To: Jan Beulich; +Cc: binutils
On Fri, Feb 14, 2020 at 7:52 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 14.02.2020 15:37, H.J. Lu wrote:
> > On Fri, Feb 14, 2020 at 6:32 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 14.02.2020 15:25, H.J. Lu wrote:
> >>> On Fri, Feb 14, 2020 at 6:23 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> On 14.02.2020 15:16, H.J. Lu wrote:
> >>>>> On Fri, Feb 14, 2020 at 5:54 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>
> >>>>>> On 14.02.2020 13:28, H.J. Lu wrote:
> >>>>>>> On Fri, Feb 14, 2020 at 4:26 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>>>
> >>>>>>>> As pointed out in "x86: replace adhoc (partly wrong) ambiguous operand
> >>>>>>>> checking for MOVSX/MOVZX" silently guessing what the programmer may have
> >>>>>>>> meant is not helpful, the more that we don't do so elsewhere anymore
> >>>>>>>> (except in cases where it is overwhelmingly likely that the other case
> >>>>>>>> isn't meant, like here for it meant to be a "sign/zero extension" from
> >>>>>>>> 16 bits to 16 bits).
> >>>>>>>>
> >>>>>>>> gas/
> >>>>>>>> 2020-02-XX Jan Beulich <jbeulich@suse.com>
> >>>>>>>>
> >>>>>>>> PR gas/25438
> >>>>>>>> * config/tc-i386.c (process_suffix): Default movsx/movzx to byte
> >>>>>>>> suffix only when destination is a word reg.
> >>>>>>>> testsuite/gas/i386/noreg16.l, testsuite/gas/i386/noreg32.l,
> >>>>>>>> testsuite/gas/i386/noreg64.l: Adjust expectations.
> >>>>>>>
> >>>>>>> No need for this since this is documented behavior of AT&T syntax.
> >>>>>>
> >>>>>> I've just looked at the documentation again: As said in the
> >>>>>> other reply to your doc change, these mnemonics aren't
> >>>>>> mentioned as legal in Solaris'es AT&T spec. And I also
> >>>>>> can't find gas doc saying so. Would you please point me at
> >>>>>> where this is being documented?
> >>>>>
> >>>>> Solaris spec doesn't mention movsx[bwl] nor movsx.
> >>>>
> >>>> Right, so where did you take from that "this is documented behavior"?
> >>>>
> >>>
> >>> Documented in gas manual.
> >>
> >> Where? As said, I did look there without finding anything to this effect.
> >
> > It is there now.
>
> Hmm, even worse: It's not there. Neither of the two doc changes of
> yours today say anything like this. Did you forget to both post a
> patch _and_ push it, or am I blind, or are you simply lying to me?
> I'm sorry for being blunt, but I'm getting really annoyed.
>
info as.info on master branch shows
The Intel-syntax extension instructions
* 'movsx' -- sign-extend 'reg8/mem8' to 'reg16'.
* 'movsx' -- sign-extend 'reg8/mem8' to 'reg32'.
* 'movsx' -- sign-extend 'reg8/mem8' to 'reg64' (x86-64 only).
* 'movsx' -- sign-extend 'reg16/mem16' to 'reg32'
* 'movsx' -- sign-extend 'reg16/mem16' to 'reg64' (x86-64 only).
* 'movsxd' -- sign-extend 'reg32/mem32' to 'reg64' (x86-64 only).
* 'movzx' -- zero-extend 'reg8/mem8' to 'reg16'.
* 'movzx' -- zero-extend 'reg8/mem8' to 'reg32'.
* 'movzx' -- zero-extend 'reg8/mem8' to 'reg64' (x86-64 only).
* 'movzx' -- zero-extend 'reg16/mem16' to 'reg32'
* 'movzx' -- zero-extend 'reg16/mem16' to 'reg64' (x86-64 only).
are called 'movsbw/movsxb/movsx', 'movsbl/movsxb/movsx',
'movsbq/movsb/movsx', 'movswl/movsxw', 'movswq/movsxw', 'movslq/movsxl',
'movzbw/movzxb/movzx', 'movzbl/movzxb/movzx', 'movzbq/movzxb/movzx',
'movzwl/movzxw' and 'movzwq/movzxw' in AT&T syntax.
--
H.J.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
2020-02-14 16:26 ` H.J. Lu
@ 2020-02-14 16:36 ` Jan Beulich
2020-02-14 16:52 ` H.J. Lu
0 siblings, 1 reply; 27+ messages in thread
From: Jan Beulich @ 2020-02-14 16:36 UTC (permalink / raw)
To: H.J. Lu; +Cc: binutils
On 14.02.2020 17:26, H.J. Lu wrote:
> On Fri, Feb 14, 2020 at 7:52 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 14.02.2020 15:37, H.J. Lu wrote:
>>> On Fri, Feb 14, 2020 at 6:32 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 14.02.2020 15:25, H.J. Lu wrote:
>>>>> On Fri, Feb 14, 2020 at 6:23 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>
>>>>>> On 14.02.2020 15:16, H.J. Lu wrote:
>>>>>>> On Fri, Feb 14, 2020 at 5:54 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>
>>>>>>>> On 14.02.2020 13:28, H.J. Lu wrote:
>>>>>>>>> On Fri, Feb 14, 2020 at 4:26 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>>>
>>>>>>>>>> As pointed out in "x86: replace adhoc (partly wrong) ambiguous operand
>>>>>>>>>> checking for MOVSX/MOVZX" silently guessing what the programmer may have
>>>>>>>>>> meant is not helpful, the more that we don't do so elsewhere anymore
>>>>>>>>>> (except in cases where it is overwhelmingly likely that the other case
>>>>>>>>>> isn't meant, like here for it meant to be a "sign/zero extension" from
>>>>>>>>>> 16 bits to 16 bits).
>>>>>>>>>>
>>>>>>>>>> gas/
>>>>>>>>>> 2020-02-XX Jan Beulich <jbeulich@suse.com>
>>>>>>>>>>
>>>>>>>>>> PR gas/25438
>>>>>>>>>> * config/tc-i386.c (process_suffix): Default movsx/movzx to byte
>>>>>>>>>> suffix only when destination is a word reg.
>>>>>>>>>> testsuite/gas/i386/noreg16.l, testsuite/gas/i386/noreg32.l,
>>>>>>>>>> testsuite/gas/i386/noreg64.l: Adjust expectations.
>>>>>>>>>
>>>>>>>>> No need for this since this is documented behavior of AT&T syntax.
>>>>>>>>
>>>>>>>> I've just looked at the documentation again: As said in the
>>>>>>>> other reply to your doc change, these mnemonics aren't
>>>>>>>> mentioned as legal in Solaris'es AT&T spec. And I also
>>>>>>>> can't find gas doc saying so. Would you please point me at
>>>>>>>> where this is being documented?
>>>>>>>
>>>>>>> Solaris spec doesn't mention movsx[bwl] nor movsx.
>>>>>>
>>>>>> Right, so where did you take from that "this is documented behavior"?
>>>>>>
>>>>>
>>>>> Documented in gas manual.
>>>>
>>>> Where? As said, I did look there without finding anything to this effect.
>>>
>>> It is there now.
>>
>> Hmm, even worse: It's not there. Neither of the two doc changes of
>> yours today say anything like this. Did you forget to both post a
>> patch _and_ push it, or am I blind, or are you simply lying to me?
>> I'm sorry for being blunt, but I'm getting really annoyed.
>>
>
> info as.info on master branch shows
>
>
> The Intel-syntax extension instructions
>
> * 'movsx' -- sign-extend 'reg8/mem8' to 'reg16'.
>
> * 'movsx' -- sign-extend 'reg8/mem8' to 'reg32'.
>
> * 'movsx' -- sign-extend 'reg8/mem8' to 'reg64' (x86-64 only).
>
> * 'movsx' -- sign-extend 'reg16/mem16' to 'reg32'
>
> * 'movsx' -- sign-extend 'reg16/mem16' to 'reg64' (x86-64 only).
>
> * 'movsxd' -- sign-extend 'reg32/mem32' to 'reg64' (x86-64 only).
>
> * 'movzx' -- zero-extend 'reg8/mem8' to 'reg16'.
>
> * 'movzx' -- zero-extend 'reg8/mem8' to 'reg32'.
>
> * 'movzx' -- zero-extend 'reg8/mem8' to 'reg64' (x86-64 only).
>
> * 'movzx' -- zero-extend 'reg16/mem16' to 'reg32'
>
> * 'movzx' -- zero-extend 'reg16/mem16' to 'reg64' (x86-64 only).
>
> are called 'movsbw/movsxb/movsx', 'movsbl/movsxb/movsx',
> 'movsbq/movsb/movsx', 'movswl/movsxw', 'movswq/movsxw', 'movslq/movsxl',
> 'movzbw/movzxb/movzx', 'movzbl/movzxb/movzx', 'movzbq/movzxb/movzx',
> 'movzwl/movzxw' and 'movzwq/movzxw' in AT&T syntax.
Which doesn't say anywhere that with a memory operand but
without suffix both default to a byte source. Yet that's the
whole point of the discussion we're having.
Jan
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
2020-02-14 16:36 ` Jan Beulich
@ 2020-02-14 16:52 ` H.J. Lu
2020-02-17 13:44 ` Jan Beulich
0 siblings, 1 reply; 27+ messages in thread
From: H.J. Lu @ 2020-02-14 16:52 UTC (permalink / raw)
To: Jan Beulich; +Cc: binutils
On Fri, Feb 14, 2020 at 8:35 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 14.02.2020 17:26, H.J. Lu wrote:
> > On Fri, Feb 14, 2020 at 7:52 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 14.02.2020 15:37, H.J. Lu wrote:
> >>> On Fri, Feb 14, 2020 at 6:32 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> On 14.02.2020 15:25, H.J. Lu wrote:
> >>>>> On Fri, Feb 14, 2020 at 6:23 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>
> >>>>>> On 14.02.2020 15:16, H.J. Lu wrote:
> >>>>>>> On Fri, Feb 14, 2020 at 5:54 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>>>
> >>>>>>>> On 14.02.2020 13:28, H.J. Lu wrote:
> >>>>>>>>> On Fri, Feb 14, 2020 at 4:26 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>> As pointed out in "x86: replace adhoc (partly wrong) ambiguous operand
> >>>>>>>>>> checking for MOVSX/MOVZX" silently guessing what the programmer may have
> >>>>>>>>>> meant is not helpful, the more that we don't do so elsewhere anymore
> >>>>>>>>>> (except in cases where it is overwhelmingly likely that the other case
> >>>>>>>>>> isn't meant, like here for it meant to be a "sign/zero extension" from
> >>>>>>>>>> 16 bits to 16 bits).
> >>>>>>>>>>
> >>>>>>>>>> gas/
> >>>>>>>>>> 2020-02-XX Jan Beulich <jbeulich@suse.com>
> >>>>>>>>>>
> >>>>>>>>>> PR gas/25438
> >>>>>>>>>> * config/tc-i386.c (process_suffix): Default movsx/movzx to byte
> >>>>>>>>>> suffix only when destination is a word reg.
> >>>>>>>>>> testsuite/gas/i386/noreg16.l, testsuite/gas/i386/noreg32.l,
> >>>>>>>>>> testsuite/gas/i386/noreg64.l: Adjust expectations.
> >>>>>>>>>
> >>>>>>>>> No need for this since this is documented behavior of AT&T syntax.
> >>>>>>>>
> >>>>>>>> I've just looked at the documentation again: As said in the
> >>>>>>>> other reply to your doc change, these mnemonics aren't
> >>>>>>>> mentioned as legal in Solaris'es AT&T spec. And I also
> >>>>>>>> can't find gas doc saying so. Would you please point me at
> >>>>>>>> where this is being documented?
> >>>>>>>
> >>>>>>> Solaris spec doesn't mention movsx[bwl] nor movsx.
> >>>>>>
> >>>>>> Right, so where did you take from that "this is documented behavior"?
> >>>>>>
> >>>>>
> >>>>> Documented in gas manual.
> >>>>
> >>>> Where? As said, I did look there without finding anything to this effect.
> >>>
> >>> It is there now.
> >>
> >> Hmm, even worse: It's not there. Neither of the two doc changes of
> >> yours today say anything like this. Did you forget to both post a
> >> patch _and_ push it, or am I blind, or are you simply lying to me?
> >> I'm sorry for being blunt, but I'm getting really annoyed.
> >>
> >
> > info as.info on master branch shows
> >
> >
> > The Intel-syntax extension instructions
> >
> > * 'movsx' -- sign-extend 'reg8/mem8' to 'reg16'.
> >
> > * 'movsx' -- sign-extend 'reg8/mem8' to 'reg32'.
> >
> > * 'movsx' -- sign-extend 'reg8/mem8' to 'reg64' (x86-64 only).
> >
> > * 'movsx' -- sign-extend 'reg16/mem16' to 'reg32'
> >
> > * 'movsx' -- sign-extend 'reg16/mem16' to 'reg64' (x86-64 only).
> >
> > * 'movsxd' -- sign-extend 'reg32/mem32' to 'reg64' (x86-64 only).
> >
> > * 'movzx' -- zero-extend 'reg8/mem8' to 'reg16'.
> >
> > * 'movzx' -- zero-extend 'reg8/mem8' to 'reg32'.
> >
> > * 'movzx' -- zero-extend 'reg8/mem8' to 'reg64' (x86-64 only).
> >
> > * 'movzx' -- zero-extend 'reg16/mem16' to 'reg32'
> >
> > * 'movzx' -- zero-extend 'reg16/mem16' to 'reg64' (x86-64 only).
> >
> > are called 'movsbw/movsxb/movsx', 'movsbl/movsxb/movsx',
> > 'movsbq/movsb/movsx', 'movswl/movsxw', 'movswq/movsxw', 'movslq/movsxl',
> > 'movzbw/movzxb/movzx', 'movzbl/movzxb/movzx', 'movzbq/movzxb/movzx',
> > 'movzwl/movzxw' and 'movzwq/movzxw' in AT&T syntax.
>
> Which doesn't say anywhere that with a memory operand but
> without suffix both default to a byte source. Yet that's the
> whole point of the discussion we're having.
>
Does 'movsbw/movsxb/movsx' cover it?
--
H.J.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
2020-02-14 16:52 ` H.J. Lu
@ 2020-02-17 13:44 ` Jan Beulich
2020-02-17 14:14 ` H.J. Lu
0 siblings, 1 reply; 27+ messages in thread
From: Jan Beulich @ 2020-02-17 13:44 UTC (permalink / raw)
To: H.J. Lu; +Cc: binutils
On 14.02.2020 17:51, H.J. Lu wrote:
> On Fri, Feb 14, 2020 at 8:35 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 14.02.2020 17:26, H.J. Lu wrote:
>>> On Fri, Feb 14, 2020 at 7:52 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 14.02.2020 15:37, H.J. Lu wrote:
>>>>> On Fri, Feb 14, 2020 at 6:32 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>
>>>>>> On 14.02.2020 15:25, H.J. Lu wrote:
>>>>>>> On Fri, Feb 14, 2020 at 6:23 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>
>>>>>>>> On 14.02.2020 15:16, H.J. Lu wrote:
>>>>>>>>> On Fri, Feb 14, 2020 at 5:54 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>>>
>>>>>>>>>> On 14.02.2020 13:28, H.J. Lu wrote:
>>>>>>>>>>> On Fri, Feb 14, 2020 at 4:26 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> As pointed out in "x86: replace adhoc (partly wrong) ambiguous operand
>>>>>>>>>>>> checking for MOVSX/MOVZX" silently guessing what the programmer may have
>>>>>>>>>>>> meant is not helpful, the more that we don't do so elsewhere anymore
>>>>>>>>>>>> (except in cases where it is overwhelmingly likely that the other case
>>>>>>>>>>>> isn't meant, like here for it meant to be a "sign/zero extension" from
>>>>>>>>>>>> 16 bits to 16 bits).
>>>>>>>>>>>>
>>>>>>>>>>>> gas/
>>>>>>>>>>>> 2020-02-XX Jan Beulich <jbeulich@suse.com>
>>>>>>>>>>>>
>>>>>>>>>>>> PR gas/25438
>>>>>>>>>>>> * config/tc-i386.c (process_suffix): Default movsx/movzx to byte
>>>>>>>>>>>> suffix only when destination is a word reg.
>>>>>>>>>>>> testsuite/gas/i386/noreg16.l, testsuite/gas/i386/noreg32.l,
>>>>>>>>>>>> testsuite/gas/i386/noreg64.l: Adjust expectations.
>>>>>>>>>>>
>>>>>>>>>>> No need for this since this is documented behavior of AT&T syntax.
>>>>>>>>>>
>>>>>>>>>> I've just looked at the documentation again: As said in the
>>>>>>>>>> other reply to your doc change, these mnemonics aren't
>>>>>>>>>> mentioned as legal in Solaris'es AT&T spec. And I also
>>>>>>>>>> can't find gas doc saying so. Would you please point me at
>>>>>>>>>> where this is being documented?
>>>>>>>>>
>>>>>>>>> Solaris spec doesn't mention movsx[bwl] nor movsx.
>>>>>>>>
>>>>>>>> Right, so where did you take from that "this is documented behavior"?
>>>>>>>>
>>>>>>>
>>>>>>> Documented in gas manual.
>>>>>>
>>>>>> Where? As said, I did look there without finding anything to this effect.
>>>>>
>>>>> It is there now.
>>>>
>>>> Hmm, even worse: It's not there. Neither of the two doc changes of
>>>> yours today say anything like this. Did you forget to both post a
>>>> patch _and_ push it, or am I blind, or are you simply lying to me?
>>>> I'm sorry for being blunt, but I'm getting really annoyed.
>>>>
>>>
>>> info as.info on master branch shows
>>>
>>>
>>> The Intel-syntax extension instructions
>>>
>>> * 'movsx' -- sign-extend 'reg8/mem8' to 'reg16'.
>>>
>>> * 'movsx' -- sign-extend 'reg8/mem8' to 'reg32'.
>>>
>>> * 'movsx' -- sign-extend 'reg8/mem8' to 'reg64' (x86-64 only).
>>>
>>> * 'movsx' -- sign-extend 'reg16/mem16' to 'reg32'
>>>
>>> * 'movsx' -- sign-extend 'reg16/mem16' to 'reg64' (x86-64 only).
>>>
>>> * 'movsxd' -- sign-extend 'reg32/mem32' to 'reg64' (x86-64 only).
>>>
>>> * 'movzx' -- zero-extend 'reg8/mem8' to 'reg16'.
>>>
>>> * 'movzx' -- zero-extend 'reg8/mem8' to 'reg32'.
>>>
>>> * 'movzx' -- zero-extend 'reg8/mem8' to 'reg64' (x86-64 only).
>>>
>>> * 'movzx' -- zero-extend 'reg16/mem16' to 'reg32'
>>>
>>> * 'movzx' -- zero-extend 'reg16/mem16' to 'reg64' (x86-64 only).
>>>
>>> are called 'movsbw/movsxb/movsx', 'movsbl/movsxb/movsx',
>>> 'movsbq/movsb/movsx', 'movswl/movsxw', 'movswq/movsxw', 'movslq/movsxl',
>>> 'movzbw/movzxb/movzx', 'movzbl/movzxb/movzx', 'movzbq/movzxb/movzx',
>>> 'movzwl/movzxw' and 'movzwq/movzxw' in AT&T syntax.
>>
>> Which doesn't say anywhere that with a memory operand but
>> without suffix both default to a byte source. Yet that's the
>> whole point of the discussion we're having.
>>
>
> Does 'movsbw/movsxb/movsx' cover it?
No, it doesn't, because its companion 'movswl/movsxw' is obviously
(to me at least) incomplete, as for register operands plain "movsx"
is suitable too. It's imo wrong in the first place to formally
name any movsx* or movzx* mnemonics to be valid in AT&T syntax. As
said, the Solaris spec doesn't mention them. Hence they're at best
hybrids, which we mean to permit, but without making them legal AT&T
syntax.
Jan
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
2020-02-17 13:44 ` Jan Beulich
@ 2020-02-17 14:14 ` H.J. Lu
2020-02-17 15:37 ` Jan Beulich
0 siblings, 1 reply; 27+ messages in thread
From: H.J. Lu @ 2020-02-17 14:14 UTC (permalink / raw)
To: Jan Beulich; +Cc: binutils
On Mon, Feb 17, 2020 at 5:44 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 14.02.2020 17:51, H.J. Lu wrote:
> > On Fri, Feb 14, 2020 at 8:35 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 14.02.2020 17:26, H.J. Lu wrote:
> >>> On Fri, Feb 14, 2020 at 7:52 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> On 14.02.2020 15:37, H.J. Lu wrote:
> >>>>> On Fri, Feb 14, 2020 at 6:32 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>
> >>>>>> On 14.02.2020 15:25, H.J. Lu wrote:
> >>>>>>> On Fri, Feb 14, 2020 at 6:23 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>>>
> >>>>>>>> On 14.02.2020 15:16, H.J. Lu wrote:
> >>>>>>>>> On Fri, Feb 14, 2020 at 5:54 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>> On 14.02.2020 13:28, H.J. Lu wrote:
> >>>>>>>>>>> On Fri, Feb 14, 2020 at 4:26 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> As pointed out in "x86: replace adhoc (partly wrong) ambiguous operand
> >>>>>>>>>>>> checking for MOVSX/MOVZX" silently guessing what the programmer may have
> >>>>>>>>>>>> meant is not helpful, the more that we don't do so elsewhere anymore
> >>>>>>>>>>>> (except in cases where it is overwhelmingly likely that the other case
> >>>>>>>>>>>> isn't meant, like here for it meant to be a "sign/zero extension" from
> >>>>>>>>>>>> 16 bits to 16 bits).
> >>>>>>>>>>>>
> >>>>>>>>>>>> gas/
> >>>>>>>>>>>> 2020-02-XX Jan Beulich <jbeulich@suse.com>
> >>>>>>>>>>>>
> >>>>>>>>>>>> PR gas/25438
> >>>>>>>>>>>> * config/tc-i386.c (process_suffix): Default movsx/movzx to byte
> >>>>>>>>>>>> suffix only when destination is a word reg.
> >>>>>>>>>>>> testsuite/gas/i386/noreg16.l, testsuite/gas/i386/noreg32.l,
> >>>>>>>>>>>> testsuite/gas/i386/noreg64.l: Adjust expectations.
> >>>>>>>>>>>
> >>>>>>>>>>> No need for this since this is documented behavior of AT&T syntax.
> >>>>>>>>>>
> >>>>>>>>>> I've just looked at the documentation again: As said in the
> >>>>>>>>>> other reply to your doc change, these mnemonics aren't
> >>>>>>>>>> mentioned as legal in Solaris'es AT&T spec. And I also
> >>>>>>>>>> can't find gas doc saying so. Would you please point me at
> >>>>>>>>>> where this is being documented?
> >>>>>>>>>
> >>>>>>>>> Solaris spec doesn't mention movsx[bwl] nor movsx.
> >>>>>>>>
> >>>>>>>> Right, so where did you take from that "this is documented behavior"?
> >>>>>>>>
> >>>>>>>
> >>>>>>> Documented in gas manual.
> >>>>>>
> >>>>>> Where? As said, I did look there without finding anything to this effect.
> >>>>>
> >>>>> It is there now.
> >>>>
> >>>> Hmm, even worse: It's not there. Neither of the two doc changes of
> >>>> yours today say anything like this. Did you forget to both post a
> >>>> patch _and_ push it, or am I blind, or are you simply lying to me?
> >>>> I'm sorry for being blunt, but I'm getting really annoyed.
> >>>>
> >>>
> >>> info as.info on master branch shows
> >>>
> >>>
> >>> The Intel-syntax extension instructions
> >>>
> >>> * 'movsx' -- sign-extend 'reg8/mem8' to 'reg16'.
> >>>
> >>> * 'movsx' -- sign-extend 'reg8/mem8' to 'reg32'.
> >>>
> >>> * 'movsx' -- sign-extend 'reg8/mem8' to 'reg64' (x86-64 only).
> >>>
> >>> * 'movsx' -- sign-extend 'reg16/mem16' to 'reg32'
> >>>
> >>> * 'movsx' -- sign-extend 'reg16/mem16' to 'reg64' (x86-64 only).
> >>>
> >>> * 'movsxd' -- sign-extend 'reg32/mem32' to 'reg64' (x86-64 only).
> >>>
> >>> * 'movzx' -- zero-extend 'reg8/mem8' to 'reg16'.
> >>>
> >>> * 'movzx' -- zero-extend 'reg8/mem8' to 'reg32'.
> >>>
> >>> * 'movzx' -- zero-extend 'reg8/mem8' to 'reg64' (x86-64 only).
> >>>
> >>> * 'movzx' -- zero-extend 'reg16/mem16' to 'reg32'
> >>>
> >>> * 'movzx' -- zero-extend 'reg16/mem16' to 'reg64' (x86-64 only).
> >>>
> >>> are called 'movsbw/movsxb/movsx', 'movsbl/movsxb/movsx',
> >>> 'movsbq/movsb/movsx', 'movswl/movsxw', 'movswq/movsxw', 'movslq/movsxl',
> >>> 'movzbw/movzxb/movzx', 'movzbl/movzxb/movzx', 'movzbq/movzxb/movzx',
> >>> 'movzwl/movzxw' and 'movzwq/movzxw' in AT&T syntax.
> >>
> >> Which doesn't say anywhere that with a memory operand but
> >> without suffix both default to a byte source. Yet that's the
> >> whole point of the discussion we're having.
> >>
> >
> > Does 'movsbw/movsxb/movsx' cover it?
>
> No, it doesn't, because its companion 'movswl/movsxw' is obviously
> (to me at least) incomplete, as for register operands plain "movsx"
> is suitable too. It's imo wrong in the first place to formally
> name any movsx* or movzx* mnemonics to be valid in AT&T syntax. As
> said, the Solaris spec doesn't mention them. Hence they're at best
> hybrids, which we mean to permit, but without making them legal AT&T
> syntax.
Not document movsxX/movsx is fine. But we should just silently accept
them since assembly codes are encoded correctly.
--
H.J.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
2020-02-17 14:14 ` H.J. Lu
@ 2020-02-17 15:37 ` Jan Beulich
2020-02-17 16:56 ` H.J. Lu
0 siblings, 1 reply; 27+ messages in thread
From: Jan Beulich @ 2020-02-17 15:37 UTC (permalink / raw)
To: H.J. Lu; +Cc: binutils
On 17.02.2020 15:14, H.J. Lu wrote:
> On Mon, Feb 17, 2020 at 5:44 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 14.02.2020 17:51, H.J. Lu wrote:
>>> On Fri, Feb 14, 2020 at 8:35 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 14.02.2020 17:26, H.J. Lu wrote:
>>>>> On Fri, Feb 14, 2020 at 7:52 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>
>>>>>> On 14.02.2020 15:37, H.J. Lu wrote:
>>>>>>> On Fri, Feb 14, 2020 at 6:32 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>
>>>>>>>> On 14.02.2020 15:25, H.J. Lu wrote:
>>>>>>>>> On Fri, Feb 14, 2020 at 6:23 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>>>
>>>>>>>>>> On 14.02.2020 15:16, H.J. Lu wrote:
>>>>>>>>>>> On Fri, Feb 14, 2020 at 5:54 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 14.02.2020 13:28, H.J. Lu wrote:
>>>>>>>>>>>>> On Fri, Feb 14, 2020 at 4:26 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As pointed out in "x86: replace adhoc (partly wrong) ambiguous operand
>>>>>>>>>>>>>> checking for MOVSX/MOVZX" silently guessing what the programmer may have
>>>>>>>>>>>>>> meant is not helpful, the more that we don't do so elsewhere anymore
>>>>>>>>>>>>>> (except in cases where it is overwhelmingly likely that the other case
>>>>>>>>>>>>>> isn't meant, like here for it meant to be a "sign/zero extension" from
>>>>>>>>>>>>>> 16 bits to 16 bits).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> gas/
>>>>>>>>>>>>>> 2020-02-XX Jan Beulich <jbeulich@suse.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> PR gas/25438
>>>>>>>>>>>>>> * config/tc-i386.c (process_suffix): Default movsx/movzx to byte
>>>>>>>>>>>>>> suffix only when destination is a word reg.
>>>>>>>>>>>>>> testsuite/gas/i386/noreg16.l, testsuite/gas/i386/noreg32.l,
>>>>>>>>>>>>>> testsuite/gas/i386/noreg64.l: Adjust expectations.
>>>>>>>>>>>>>
>>>>>>>>>>>>> No need for this since this is documented behavior of AT&T syntax.
>>>>>>>>>>>>
>>>>>>>>>>>> I've just looked at the documentation again: As said in the
>>>>>>>>>>>> other reply to your doc change, these mnemonics aren't
>>>>>>>>>>>> mentioned as legal in Solaris'es AT&T spec. And I also
>>>>>>>>>>>> can't find gas doc saying so. Would you please point me at
>>>>>>>>>>>> where this is being documented?
>>>>>>>>>>>
>>>>>>>>>>> Solaris spec doesn't mention movsx[bwl] nor movsx.
>>>>>>>>>>
>>>>>>>>>> Right, so where did you take from that "this is documented behavior"?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Documented in gas manual.
>>>>>>>>
>>>>>>>> Where? As said, I did look there without finding anything to this effect.
>>>>>>>
>>>>>>> It is there now.
>>>>>>
>>>>>> Hmm, even worse: It's not there. Neither of the two doc changes of
>>>>>> yours today say anything like this. Did you forget to both post a
>>>>>> patch _and_ push it, or am I blind, or are you simply lying to me?
>>>>>> I'm sorry for being blunt, but I'm getting really annoyed.
>>>>>>
>>>>>
>>>>> info as.info on master branch shows
>>>>>
>>>>>
>>>>> The Intel-syntax extension instructions
>>>>>
>>>>> * 'movsx' -- sign-extend 'reg8/mem8' to 'reg16'.
>>>>>
>>>>> * 'movsx' -- sign-extend 'reg8/mem8' to 'reg32'.
>>>>>
>>>>> * 'movsx' -- sign-extend 'reg8/mem8' to 'reg64' (x86-64 only).
>>>>>
>>>>> * 'movsx' -- sign-extend 'reg16/mem16' to 'reg32'
>>>>>
>>>>> * 'movsx' -- sign-extend 'reg16/mem16' to 'reg64' (x86-64 only).
>>>>>
>>>>> * 'movsxd' -- sign-extend 'reg32/mem32' to 'reg64' (x86-64 only).
>>>>>
>>>>> * 'movzx' -- zero-extend 'reg8/mem8' to 'reg16'.
>>>>>
>>>>> * 'movzx' -- zero-extend 'reg8/mem8' to 'reg32'.
>>>>>
>>>>> * 'movzx' -- zero-extend 'reg8/mem8' to 'reg64' (x86-64 only).
>>>>>
>>>>> * 'movzx' -- zero-extend 'reg16/mem16' to 'reg32'
>>>>>
>>>>> * 'movzx' -- zero-extend 'reg16/mem16' to 'reg64' (x86-64 only).
>>>>>
>>>>> are called 'movsbw/movsxb/movsx', 'movsbl/movsxb/movsx',
>>>>> 'movsbq/movsb/movsx', 'movswl/movsxw', 'movswq/movsxw', 'movslq/movsxl',
>>>>> 'movzbw/movzxb/movzx', 'movzbl/movzxb/movzx', 'movzbq/movzxb/movzx',
>>>>> 'movzwl/movzxw' and 'movzwq/movzxw' in AT&T syntax.
>>>>
>>>> Which doesn't say anywhere that with a memory operand but
>>>> without suffix both default to a byte source. Yet that's the
>>>> whole point of the discussion we're having.
>>>>
>>>
>>> Does 'movsbw/movsxb/movsx' cover it?
>>
>> No, it doesn't, because its companion 'movswl/movsxw' is obviously
>> (to me at least) incomplete, as for register operands plain "movsx"
>> is suitable too. It's imo wrong in the first place to formally
>> name any movsx* or movzx* mnemonics to be valid in AT&T syntax. As
>> said, the Solaris spec doesn't mention them. Hence they're at best
>> hybrids, which we mean to permit, but without making them legal AT&T
>> syntax.
>
> Not document movsxX/movsx is fine. But we should just silently accept
> them since assembly codes are encoded correctly.
We should accept them, yes, _but not silently_. Even less so without
it being written down anywhere that this is the behavior to expect.
Jan
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
2020-02-17 15:37 ` Jan Beulich
@ 2020-02-17 16:56 ` H.J. Lu
2020-02-17 17:04 ` Jan Beulich
0 siblings, 1 reply; 27+ messages in thread
From: H.J. Lu @ 2020-02-17 16:56 UTC (permalink / raw)
To: Jan Beulich; +Cc: binutils
On Mon, Feb 17, 2020 at 7:37 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 17.02.2020 15:14, H.J. Lu wrote:
> > On Mon, Feb 17, 2020 at 5:44 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 14.02.2020 17:51, H.J. Lu wrote:
> >>> On Fri, Feb 14, 2020 at 8:35 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> On 14.02.2020 17:26, H.J. Lu wrote:
> >>>>> On Fri, Feb 14, 2020 at 7:52 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>
> >>>>>> On 14.02.2020 15:37, H.J. Lu wrote:
> >>>>>>> On Fri, Feb 14, 2020 at 6:32 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>>>
> >>>>>>>> On 14.02.2020 15:25, H.J. Lu wrote:
> >>>>>>>>> On Fri, Feb 14, 2020 at 6:23 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>> On 14.02.2020 15:16, H.J. Lu wrote:
> >>>>>>>>>>> On Fri, Feb 14, 2020 at 5:54 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 14.02.2020 13:28, H.J. Lu wrote:
> >>>>>>>>>>>>> On Fri, Feb 14, 2020 at 4:26 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> As pointed out in "x86: replace adhoc (partly wrong) ambiguous operand
> >>>>>>>>>>>>>> checking for MOVSX/MOVZX" silently guessing what the programmer may have
> >>>>>>>>>>>>>> meant is not helpful, the more that we don't do so elsewhere anymore
> >>>>>>>>>>>>>> (except in cases where it is overwhelmingly likely that the other case
> >>>>>>>>>>>>>> isn't meant, like here for it meant to be a "sign/zero extension" from
> >>>>>>>>>>>>>> 16 bits to 16 bits).
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> gas/
> >>>>>>>>>>>>>> 2020-02-XX Jan Beulich <jbeulich@suse.com>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> PR gas/25438
> >>>>>>>>>>>>>> * config/tc-i386.c (process_suffix): Default movsx/movzx to byte
> >>>>>>>>>>>>>> suffix only when destination is a word reg.
> >>>>>>>>>>>>>> testsuite/gas/i386/noreg16.l, testsuite/gas/i386/noreg32.l,
> >>>>>>>>>>>>>> testsuite/gas/i386/noreg64.l: Adjust expectations.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> No need for this since this is documented behavior of AT&T syntax.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I've just looked at the documentation again: As said in the
> >>>>>>>>>>>> other reply to your doc change, these mnemonics aren't
> >>>>>>>>>>>> mentioned as legal in Solaris'es AT&T spec. And I also
> >>>>>>>>>>>> can't find gas doc saying so. Would you please point me at
> >>>>>>>>>>>> where this is being documented?
> >>>>>>>>>>>
> >>>>>>>>>>> Solaris spec doesn't mention movsx[bwl] nor movsx.
> >>>>>>>>>>
> >>>>>>>>>> Right, so where did you take from that "this is documented behavior"?
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Documented in gas manual.
> >>>>>>>>
> >>>>>>>> Where? As said, I did look there without finding anything to this effect.
> >>>>>>>
> >>>>>>> It is there now.
> >>>>>>
> >>>>>> Hmm, even worse: It's not there. Neither of the two doc changes of
> >>>>>> yours today say anything like this. Did you forget to both post a
> >>>>>> patch _and_ push it, or am I blind, or are you simply lying to me?
> >>>>>> I'm sorry for being blunt, but I'm getting really annoyed.
> >>>>>>
> >>>>>
> >>>>> info as.info on master branch shows
> >>>>>
> >>>>>
> >>>>> The Intel-syntax extension instructions
> >>>>>
> >>>>> * 'movsx' -- sign-extend 'reg8/mem8' to 'reg16'.
> >>>>>
> >>>>> * 'movsx' -- sign-extend 'reg8/mem8' to 'reg32'.
> >>>>>
> >>>>> * 'movsx' -- sign-extend 'reg8/mem8' to 'reg64' (x86-64 only).
> >>>>>
> >>>>> * 'movsx' -- sign-extend 'reg16/mem16' to 'reg32'
> >>>>>
> >>>>> * 'movsx' -- sign-extend 'reg16/mem16' to 'reg64' (x86-64 only).
> >>>>>
> >>>>> * 'movsxd' -- sign-extend 'reg32/mem32' to 'reg64' (x86-64 only).
> >>>>>
> >>>>> * 'movzx' -- zero-extend 'reg8/mem8' to 'reg16'.
> >>>>>
> >>>>> * 'movzx' -- zero-extend 'reg8/mem8' to 'reg32'.
> >>>>>
> >>>>> * 'movzx' -- zero-extend 'reg8/mem8' to 'reg64' (x86-64 only).
> >>>>>
> >>>>> * 'movzx' -- zero-extend 'reg16/mem16' to 'reg32'
> >>>>>
> >>>>> * 'movzx' -- zero-extend 'reg16/mem16' to 'reg64' (x86-64 only).
> >>>>>
> >>>>> are called 'movsbw/movsxb/movsx', 'movsbl/movsxb/movsx',
> >>>>> 'movsbq/movsb/movsx', 'movswl/movsxw', 'movswq/movsxw', 'movslq/movsxl',
> >>>>> 'movzbw/movzxb/movzx', 'movzbl/movzxb/movzx', 'movzbq/movzxb/movzx',
> >>>>> 'movzwl/movzxw' and 'movzwq/movzxw' in AT&T syntax.
> >>>>
> >>>> Which doesn't say anywhere that with a memory operand but
> >>>> without suffix both default to a byte source. Yet that's the
> >>>> whole point of the discussion we're having.
> >>>>
> >>>
> >>> Does 'movsbw/movsxb/movsx' cover it?
> >>
> >> No, it doesn't, because its companion 'movswl/movsxw' is obviously
> >> (to me at least) incomplete, as for register operands plain "movsx"
> >> is suitable too. It's imo wrong in the first place to formally
> >> name any movsx* or movzx* mnemonics to be valid in AT&T syntax. As
> >> said, the Solaris spec doesn't mention them. Hence they're at best
> >> hybrids, which we mean to permit, but without making them legal AT&T
> >> syntax.
> >
> > Not document movsxX/movsx is fine. But we should just silently accept
> > them since assembly codes are encoded correctly.
>
> We should accept them, yes, _but not silently_. Even less so without
> it being written down anywhere that this is the behavior to expect.
Please submit a patch to improve gas manual to document such.
--
H.J.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
2020-02-17 16:56 ` H.J. Lu
@ 2020-02-17 17:04 ` Jan Beulich
2020-02-17 17:19 ` H.J. Lu
0 siblings, 1 reply; 27+ messages in thread
From: Jan Beulich @ 2020-02-17 17:04 UTC (permalink / raw)
To: H.J. Lu; +Cc: binutils
On 17.02.2020 17:55, H.J. Lu wrote:
> On Mon, Feb 17, 2020 at 7:37 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 17.02.2020 15:14, H.J. Lu wrote:
>>> On Mon, Feb 17, 2020 at 5:44 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 14.02.2020 17:51, H.J. Lu wrote:
>>>>> On Fri, Feb 14, 2020 at 8:35 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>
>>>>>> On 14.02.2020 17:26, H.J. Lu wrote:
>>>>>>> On Fri, Feb 14, 2020 at 7:52 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>
>>>>>>>> On 14.02.2020 15:37, H.J. Lu wrote:
>>>>>>>>> On Fri, Feb 14, 2020 at 6:32 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>>>
>>>>>>>>>> On 14.02.2020 15:25, H.J. Lu wrote:
>>>>>>>>>>> On Fri, Feb 14, 2020 at 6:23 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 14.02.2020 15:16, H.J. Lu wrote:
>>>>>>>>>>>>> On Fri, Feb 14, 2020 at 5:54 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 14.02.2020 13:28, H.J. Lu wrote:
>>>>>>>>>>>>>>> On Fri, Feb 14, 2020 at 4:26 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> As pointed out in "x86: replace adhoc (partly wrong) ambiguous operand
>>>>>>>>>>>>>>>> checking for MOVSX/MOVZX" silently guessing what the programmer may have
>>>>>>>>>>>>>>>> meant is not helpful, the more that we don't do so elsewhere anymore
>>>>>>>>>>>>>>>> (except in cases where it is overwhelmingly likely that the other case
>>>>>>>>>>>>>>>> isn't meant, like here for it meant to be a "sign/zero extension" from
>>>>>>>>>>>>>>>> 16 bits to 16 bits).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> gas/
>>>>>>>>>>>>>>>> 2020-02-XX Jan Beulich <jbeulich@suse.com>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> PR gas/25438
>>>>>>>>>>>>>>>> * config/tc-i386.c (process_suffix): Default movsx/movzx to byte
>>>>>>>>>>>>>>>> suffix only when destination is a word reg.
>>>>>>>>>>>>>>>> testsuite/gas/i386/noreg16.l, testsuite/gas/i386/noreg32.l,
>>>>>>>>>>>>>>>> testsuite/gas/i386/noreg64.l: Adjust expectations.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No need for this since this is documented behavior of AT&T syntax.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've just looked at the documentation again: As said in the
>>>>>>>>>>>>>> other reply to your doc change, these mnemonics aren't
>>>>>>>>>>>>>> mentioned as legal in Solaris'es AT&T spec. And I also
>>>>>>>>>>>>>> can't find gas doc saying so. Would you please point me at
>>>>>>>>>>>>>> where this is being documented?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Solaris spec doesn't mention movsx[bwl] nor movsx.
>>>>>>>>>>>>
>>>>>>>>>>>> Right, so where did you take from that "this is documented behavior"?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Documented in gas manual.
>>>>>>>>>>
>>>>>>>>>> Where? As said, I did look there without finding anything to this effect.
>>>>>>>>>
>>>>>>>>> It is there now.
>>>>>>>>
>>>>>>>> Hmm, even worse: It's not there. Neither of the two doc changes of
>>>>>>>> yours today say anything like this. Did you forget to both post a
>>>>>>>> patch _and_ push it, or am I blind, or are you simply lying to me?
>>>>>>>> I'm sorry for being blunt, but I'm getting really annoyed.
>>>>>>>>
>>>>>>>
>>>>>>> info as.info on master branch shows
>>>>>>>
>>>>>>>
>>>>>>> The Intel-syntax extension instructions
>>>>>>>
>>>>>>> * 'movsx' -- sign-extend 'reg8/mem8' to 'reg16'.
>>>>>>>
>>>>>>> * 'movsx' -- sign-extend 'reg8/mem8' to 'reg32'.
>>>>>>>
>>>>>>> * 'movsx' -- sign-extend 'reg8/mem8' to 'reg64' (x86-64 only).
>>>>>>>
>>>>>>> * 'movsx' -- sign-extend 'reg16/mem16' to 'reg32'
>>>>>>>
>>>>>>> * 'movsx' -- sign-extend 'reg16/mem16' to 'reg64' (x86-64 only).
>>>>>>>
>>>>>>> * 'movsxd' -- sign-extend 'reg32/mem32' to 'reg64' (x86-64 only).
>>>>>>>
>>>>>>> * 'movzx' -- zero-extend 'reg8/mem8' to 'reg16'.
>>>>>>>
>>>>>>> * 'movzx' -- zero-extend 'reg8/mem8' to 'reg32'.
>>>>>>>
>>>>>>> * 'movzx' -- zero-extend 'reg8/mem8' to 'reg64' (x86-64 only).
>>>>>>>
>>>>>>> * 'movzx' -- zero-extend 'reg16/mem16' to 'reg32'
>>>>>>>
>>>>>>> * 'movzx' -- zero-extend 'reg16/mem16' to 'reg64' (x86-64 only).
>>>>>>>
>>>>>>> are called 'movsbw/movsxb/movsx', 'movsbl/movsxb/movsx',
>>>>>>> 'movsbq/movsb/movsx', 'movswl/movsxw', 'movswq/movsxw', 'movslq/movsxl',
>>>>>>> 'movzbw/movzxb/movzx', 'movzbl/movzxb/movzx', 'movzbq/movzxb/movzx',
>>>>>>> 'movzwl/movzxw' and 'movzwq/movzxw' in AT&T syntax.
>>>>>>
>>>>>> Which doesn't say anywhere that with a memory operand but
>>>>>> without suffix both default to a byte source. Yet that's the
>>>>>> whole point of the discussion we're having.
>>>>>>
>>>>>
>>>>> Does 'movsbw/movsxb/movsx' cover it?
>>>>
>>>> No, it doesn't, because its companion 'movswl/movsxw' is obviously
>>>> (to me at least) incomplete, as for register operands plain "movsx"
>>>> is suitable too. It's imo wrong in the first place to formally
>>>> name any movsx* or movzx* mnemonics to be valid in AT&T syntax. As
>>>> said, the Solaris spec doesn't mention them. Hence they're at best
>>>> hybrids, which we mean to permit, but without making them legal AT&T
>>>> syntax.
>>>
>>> Not document movsxX/movsx is fine. But we should just silently accept
>>> them since assembly codes are encoded correctly.
>>
>> We should accept them, yes, _but not silently_. Even less so without
>> it being written down anywhere that this is the behavior to expect.
>
> Please submit a patch to improve gas manual to document such.
Just like on the other thread - I'm not going to document what I
believe is wrong behavior. If I am to add documentation here, I'd
add it such that afterwards the implementation will need bringing
in sync. Also, let's not forget - you objected to a code change
mine on the basis that the way you wanted it is documented
_somewhere_. And now you ask _me_ to add this documentation?
Jan
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
2020-02-17 17:04 ` Jan Beulich
@ 2020-02-17 17:19 ` H.J. Lu
2020-02-18 7:44 ` Jan Beulich
0 siblings, 1 reply; 27+ messages in thread
From: H.J. Lu @ 2020-02-17 17:19 UTC (permalink / raw)
To: Jan Beulich; +Cc: binutils
On Mon, Feb 17, 2020 at 9:04 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 17.02.2020 17:55, H.J. Lu wrote:
> > On Mon, Feb 17, 2020 at 7:37 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 17.02.2020 15:14, H.J. Lu wrote:
> >>> On Mon, Feb 17, 2020 at 5:44 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> On 14.02.2020 17:51, H.J. Lu wrote:
> >>>>> On Fri, Feb 14, 2020 at 8:35 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>
> >>>>>> On 14.02.2020 17:26, H.J. Lu wrote:
> >>>>>>> On Fri, Feb 14, 2020 at 7:52 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>>>
> >>>>>>>> On 14.02.2020 15:37, H.J. Lu wrote:
> >>>>>>>>> On Fri, Feb 14, 2020 at 6:32 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>> On 14.02.2020 15:25, H.J. Lu wrote:
> >>>>>>>>>>> On Fri, Feb 14, 2020 at 6:23 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 14.02.2020 15:16, H.J. Lu wrote:
> >>>>>>>>>>>>> On Fri, Feb 14, 2020 at 5:54 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 14.02.2020 13:28, H.J. Lu wrote:
> >>>>>>>>>>>>>>> On Fri, Feb 14, 2020 at 4:26 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> As pointed out in "x86: replace adhoc (partly wrong) ambiguous operand
> >>>>>>>>>>>>>>>> checking for MOVSX/MOVZX" silently guessing what the programmer may have
> >>>>>>>>>>>>>>>> meant is not helpful, the more that we don't do so elsewhere anymore
> >>>>>>>>>>>>>>>> (except in cases where it is overwhelmingly likely that the other case
> >>>>>>>>>>>>>>>> isn't meant, like here for it meant to be a "sign/zero extension" from
> >>>>>>>>>>>>>>>> 16 bits to 16 bits).
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> gas/
> >>>>>>>>>>>>>>>> 2020-02-XX Jan Beulich <jbeulich@suse.com>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> PR gas/25438
> >>>>>>>>>>>>>>>> * config/tc-i386.c (process_suffix): Default movsx/movzx to byte
> >>>>>>>>>>>>>>>> suffix only when destination is a word reg.
> >>>>>>>>>>>>>>>> testsuite/gas/i386/noreg16.l, testsuite/gas/i386/noreg32.l,
> >>>>>>>>>>>>>>>> testsuite/gas/i386/noreg64.l: Adjust expectations.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> No need for this since this is documented behavior of AT&T syntax.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I've just looked at the documentation again: As said in the
> >>>>>>>>>>>>>> other reply to your doc change, these mnemonics aren't
> >>>>>>>>>>>>>> mentioned as legal in Solaris'es AT&T spec. And I also
> >>>>>>>>>>>>>> can't find gas doc saying so. Would you please point me at
> >>>>>>>>>>>>>> where this is being documented?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Solaris spec doesn't mention movsx[bwl] nor movsx.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Right, so where did you take from that "this is documented behavior"?
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Documented in gas manual.
> >>>>>>>>>>
> >>>>>>>>>> Where? As said, I did look there without finding anything to this effect.
> >>>>>>>>>
> >>>>>>>>> It is there now.
> >>>>>>>>
> >>>>>>>> Hmm, even worse: It's not there. Neither of the two doc changes of
> >>>>>>>> yours today say anything like this. Did you forget to both post a
> >>>>>>>> patch _and_ push it, or am I blind, or are you simply lying to me?
> >>>>>>>> I'm sorry for being blunt, but I'm getting really annoyed.
> >>>>>>>>
> >>>>>>>
> >>>>>>> info as.info on master branch shows
> >>>>>>>
> >>>>>>>
> >>>>>>> The Intel-syntax extension instructions
> >>>>>>>
> >>>>>>> * 'movsx' -- sign-extend 'reg8/mem8' to 'reg16'.
> >>>>>>>
> >>>>>>> * 'movsx' -- sign-extend 'reg8/mem8' to 'reg32'.
> >>>>>>>
> >>>>>>> * 'movsx' -- sign-extend 'reg8/mem8' to 'reg64' (x86-64 only).
> >>>>>>>
> >>>>>>> * 'movsx' -- sign-extend 'reg16/mem16' to 'reg32'
> >>>>>>>
> >>>>>>> * 'movsx' -- sign-extend 'reg16/mem16' to 'reg64' (x86-64 only).
> >>>>>>>
> >>>>>>> * 'movsxd' -- sign-extend 'reg32/mem32' to 'reg64' (x86-64 only).
> >>>>>>>
> >>>>>>> * 'movzx' -- zero-extend 'reg8/mem8' to 'reg16'.
> >>>>>>>
> >>>>>>> * 'movzx' -- zero-extend 'reg8/mem8' to 'reg32'.
> >>>>>>>
> >>>>>>> * 'movzx' -- zero-extend 'reg8/mem8' to 'reg64' (x86-64 only).
> >>>>>>>
> >>>>>>> * 'movzx' -- zero-extend 'reg16/mem16' to 'reg32'
> >>>>>>>
> >>>>>>> * 'movzx' -- zero-extend 'reg16/mem16' to 'reg64' (x86-64 only).
> >>>>>>>
> >>>>>>> are called 'movsbw/movsxb/movsx', 'movsbl/movsxb/movsx',
> >>>>>>> 'movsbq/movsb/movsx', 'movswl/movsxw', 'movswq/movsxw', 'movslq/movsxl',
> >>>>>>> 'movzbw/movzxb/movzx', 'movzbl/movzxb/movzx', 'movzbq/movzxb/movzx',
> >>>>>>> 'movzwl/movzxw' and 'movzwq/movzxw' in AT&T syntax.
> >>>>>>
> >>>>>> Which doesn't say anywhere that with a memory operand but
> >>>>>> without suffix both default to a byte source. Yet that's the
> >>>>>> whole point of the discussion we're having.
> >>>>>>
> >>>>>
> >>>>> Does 'movsbw/movsxb/movsx' cover it?
> >>>>
> >>>> No, it doesn't, because its companion 'movswl/movsxw' is obviously
> >>>> (to me at least) incomplete, as for register operands plain "movsx"
> >>>> is suitable too. It's imo wrong in the first place to formally
> >>>> name any movsx* or movzx* mnemonics to be valid in AT&T syntax. As
> >>>> said, the Solaris spec doesn't mention them. Hence they're at best
> >>>> hybrids, which we mean to permit, but without making them legal AT&T
> >>>> syntax.
> >>>
> >>> Not document movsxX/movsx is fine. But we should just silently accept
> >>> them since assembly codes are encoded correctly.
> >>
> >> We should accept them, yes, _but not silently_. Even less so without
> >> it being written down anywhere that this is the behavior to expect.
> >
> > Please submit a patch to improve gas manual to document such.
>
> Just like on the other thread - I'm not going to document what I
> believe is wrong behavior. If I am to add documentation here, I'd
> add it such that afterwards the implementation will need bringing
> in sync. Also, let's not forget - you objected to a code change
> mine on the basis that the way you wanted it is documented
> _somewhere_. And now you ask _me_ to add this documentation?
I did add documentation.
--
H.J.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
2020-02-17 17:19 ` H.J. Lu
@ 2020-02-18 7:44 ` Jan Beulich
0 siblings, 0 replies; 27+ messages in thread
From: Jan Beulich @ 2020-02-18 7:44 UTC (permalink / raw)
To: H.J. Lu; +Cc: binutils
On 17.02.2020 18:18, H.J. Lu wrote:
> On Mon, Feb 17, 2020 at 9:04 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 17.02.2020 17:55, H.J. Lu wrote:
>>> On Mon, Feb 17, 2020 at 7:37 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 17.02.2020 15:14, H.J. Lu wrote:
>>>>> On Mon, Feb 17, 2020 at 5:44 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>
>>>>>> On 14.02.2020 17:51, H.J. Lu wrote:
>>>>>>> On Fri, Feb 14, 2020 at 8:35 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>
>>>>>>>> On 14.02.2020 17:26, H.J. Lu wrote:
>>>>>>>>> On Fri, Feb 14, 2020 at 7:52 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>>>
>>>>>>>>>> On 14.02.2020 15:37, H.J. Lu wrote:
>>>>>>>>>>> On Fri, Feb 14, 2020 at 6:32 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 14.02.2020 15:25, H.J. Lu wrote:
>>>>>>>>>>>>> On Fri, Feb 14, 2020 at 6:23 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 14.02.2020 15:16, H.J. Lu wrote:
>>>>>>>>>>>>>>> On Fri, Feb 14, 2020 at 5:54 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 14.02.2020 13:28, H.J. Lu wrote:
>>>>>>>>>>>>>>>>> On Fri, Feb 14, 2020 at 4:26 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> As pointed out in "x86: replace adhoc (partly wrong) ambiguous operand
>>>>>>>>>>>>>>>>>> checking for MOVSX/MOVZX" silently guessing what the programmer may have
>>>>>>>>>>>>>>>>>> meant is not helpful, the more that we don't do so elsewhere anymore
>>>>>>>>>>>>>>>>>> (except in cases where it is overwhelmingly likely that the other case
>>>>>>>>>>>>>>>>>> isn't meant, like here for it meant to be a "sign/zero extension" from
>>>>>>>>>>>>>>>>>> 16 bits to 16 bits).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> gas/
>>>>>>>>>>>>>>>>>> 2020-02-XX Jan Beulich <jbeulich@suse.com>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> PR gas/25438
>>>>>>>>>>>>>>>>>> * config/tc-i386.c (process_suffix): Default movsx/movzx to byte
>>>>>>>>>>>>>>>>>> suffix only when destination is a word reg.
>>>>>>>>>>>>>>>>>> testsuite/gas/i386/noreg16.l, testsuite/gas/i386/noreg32.l,
>>>>>>>>>>>>>>>>>> testsuite/gas/i386/noreg64.l: Adjust expectations.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No need for this since this is documented behavior of AT&T syntax.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I've just looked at the documentation again: As said in the
>>>>>>>>>>>>>>>> other reply to your doc change, these mnemonics aren't
>>>>>>>>>>>>>>>> mentioned as legal in Solaris'es AT&T spec. And I also
>>>>>>>>>>>>>>>> can't find gas doc saying so. Would you please point me at
>>>>>>>>>>>>>>>> where this is being documented?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Solaris spec doesn't mention movsx[bwl] nor movsx.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Right, so where did you take from that "this is documented behavior"?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Documented in gas manual.
>>>>>>>>>>>>
>>>>>>>>>>>> Where? As said, I did look there without finding anything to this effect.
>>>>>>>>>>>
>>>>>>>>>>> It is there now.
>>>>>>>>>>
>>>>>>>>>> Hmm, even worse: It's not there. Neither of the two doc changes of
>>>>>>>>>> yours today say anything like this. Did you forget to both post a
>>>>>>>>>> patch _and_ push it, or am I blind, or are you simply lying to me?
>>>>>>>>>> I'm sorry for being blunt, but I'm getting really annoyed.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> info as.info on master branch shows
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The Intel-syntax extension instructions
>>>>>>>>>
>>>>>>>>> * 'movsx' -- sign-extend 'reg8/mem8' to 'reg16'.
>>>>>>>>>
>>>>>>>>> * 'movsx' -- sign-extend 'reg8/mem8' to 'reg32'.
>>>>>>>>>
>>>>>>>>> * 'movsx' -- sign-extend 'reg8/mem8' to 'reg64' (x86-64 only).
>>>>>>>>>
>>>>>>>>> * 'movsx' -- sign-extend 'reg16/mem16' to 'reg32'
>>>>>>>>>
>>>>>>>>> * 'movsx' -- sign-extend 'reg16/mem16' to 'reg64' (x86-64 only).
>>>>>>>>>
>>>>>>>>> * 'movsxd' -- sign-extend 'reg32/mem32' to 'reg64' (x86-64 only).
>>>>>>>>>
>>>>>>>>> * 'movzx' -- zero-extend 'reg8/mem8' to 'reg16'.
>>>>>>>>>
>>>>>>>>> * 'movzx' -- zero-extend 'reg8/mem8' to 'reg32'.
>>>>>>>>>
>>>>>>>>> * 'movzx' -- zero-extend 'reg8/mem8' to 'reg64' (x86-64 only).
>>>>>>>>>
>>>>>>>>> * 'movzx' -- zero-extend 'reg16/mem16' to 'reg32'
>>>>>>>>>
>>>>>>>>> * 'movzx' -- zero-extend 'reg16/mem16' to 'reg64' (x86-64 only).
>>>>>>>>>
>>>>>>>>> are called 'movsbw/movsxb/movsx', 'movsbl/movsxb/movsx',
>>>>>>>>> 'movsbq/movsb/movsx', 'movswl/movsxw', 'movswq/movsxw', 'movslq/movsxl',
>>>>>>>>> 'movzbw/movzxb/movzx', 'movzbl/movzxb/movzx', 'movzbq/movzxb/movzx',
>>>>>>>>> 'movzwl/movzxw' and 'movzwq/movzxw' in AT&T syntax.
>>>>>>>>
>>>>>>>> Which doesn't say anywhere that with a memory operand but
>>>>>>>> without suffix both default to a byte source. Yet that's the
>>>>>>>> whole point of the discussion we're having.
>>>>>>>>
>>>>>>>
>>>>>>> Does 'movsbw/movsxb/movsx' cover it?
>>>>>>
>>>>>> No, it doesn't, because its companion 'movswl/movsxw' is obviously
>>>>>> (to me at least) incomplete, as for register operands plain "movsx"
>>>>>> is suitable too. It's imo wrong in the first place to formally
>>>>>> name any movsx* or movzx* mnemonics to be valid in AT&T syntax. As
>>>>>> said, the Solaris spec doesn't mention them. Hence they're at best
>>>>>> hybrids, which we mean to permit, but without making them legal AT&T
>>>>>> syntax.
>>>>>
>>>>> Not document movsxX/movsx is fine. But we should just silently accept
>>>>> them since assembly codes are encoded correctly.
>>>>
>>>> We should accept them, yes, _but not silently_. Even less so without
>>>> it being written down anywhere that this is the behavior to expect.
>>>
>>> Please submit a patch to improve gas manual to document such.
>>
>> Just like on the other thread - I'm not going to document what I
>> believe is wrong behavior. If I am to add documentation here, I'd
>> add it such that afterwards the implementation will need bringing
>> in sync. Also, let's not forget - you objected to a code change
>> mine on the basis that the way you wanted it is documented
>> _somewhere_. And now you ask _me_ to add this documentation?
>
> I did add documentation.
You mean the part still quoted above? As you were able to see, even
being aware of the context I couldn't interpret it as even coming
close to what you meant to document. It does in no way support your
claim of there being a defaulting to byte source. (And of course it
also continues to be the case that you claimed such documentation
was in place _before_ you actually added this piece.) I don't think
I'm in the slightest convinced that suppressing the warning in this
particular case is warranted. In fact the process of the discussion
has convinced me even further that a warning _is needed_ (and not
just warranted) here.
Jan
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2020-02-18 7:44 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-14 12:21 [PATCH v8 0/2] x86: replace adhoc (partly wrong) ambiguous operand checking for MOVSX/MOVZX Jan Beulich
2020-02-14 12:26 ` [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous " Jan Beulich
2020-02-14 12:28 ` H.J. Lu
2020-02-14 13:13 ` Jan Beulich
2020-02-14 13:54 ` Jan Beulich
2020-02-14 14:16 ` H.J. Lu
2020-02-14 14:23 ` Jan Beulich
2020-02-14 14:26 ` H.J. Lu
2020-02-14 14:32 ` Jan Beulich
2020-02-14 14:38 ` H.J. Lu
2020-02-14 15:47 ` Jan Beulich
2020-02-14 15:52 ` Jan Beulich
2020-02-14 16:26 ` H.J. Lu
2020-02-14 16:36 ` Jan Beulich
2020-02-14 16:52 ` H.J. Lu
2020-02-17 13:44 ` Jan Beulich
2020-02-17 14:14 ` H.J. Lu
2020-02-17 15:37 ` Jan Beulich
2020-02-17 16:56 ` H.J. Lu
2020-02-17 17:04 ` Jan Beulich
2020-02-17 17:19 ` H.J. Lu
2020-02-18 7:44 ` Jan Beulich
2020-02-14 12:26 ` [PATCH v8 1/2] x86: replace adhoc (partly wrong) ambiguous operand checking " Jan Beulich
2020-02-14 12:31 ` H.J. Lu
2020-02-14 12:34 ` H.J. Lu
2020-02-14 12:42 ` Jan Beulich
2020-02-14 12:49 ` H.J. Lu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).