* [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 1/2] " Jan Beulich 2020-02-14 12:26 ` [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous " 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 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 ` Jan Beulich 2020-02-14 12:31 ` H.J. Lu 2020-02-14 12:34 ` H.J. Lu 2020-02-14 12:26 ` [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous " Jan Beulich 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 1/2] x86: replace adhoc (partly wrong) ambiguous operand checking for MOVSX/MOVZX 2020-02-14 12:26 ` [PATCH v8 1/2] " 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] " 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
* [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 ` [PATCH v8 1/2] " Jan Beulich @ 2020-02-14 12:26 ` Jan Beulich 2020-02-14 12:28 ` H.J. Lu 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
* 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 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 1/2] " 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 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
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).