[Bug gas/25438] New: x86 MOVZ* anomalies for unusual/wrong operand combinations

[jbeulich at suse dot com]

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

            Bug ID: 25438
           Summary: x86 MOVZ* anomalies for unusual/wrong operand
                    combinations
           Product: binutils
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gas
          Assignee: unassigned at sourceware dot org
          Reporter: jbeulich at suse dot com
  Target Milestone: ---

The tests proposed to be added by

https://sourceware.org/ml/binutils/2019-12/msg00354.html

demonstrate some inconsistencies which get addressed by the next patch of the
series:

https://sourceware.org/ml/binutils/2019-12/msg00346.html

The condensed differences from before the patch (and 2.33.1 behavior) and after
it can be seen in the following diff of the respective listing files:

--- movx.l
+++ movx.l
@@ -7,39 +7,43 @@
    4                           movsbw  %al, %ecx
    5                           movsbl  %al, %cx
    6                   
-   7 ???? 660FB6C8             movzbw  %al, %ecx
-   8 ???? 0FB6C8               movzbl  %al, %cx
+   7 ???? 0FB6C8               movzbw  %al, %ecx
+****  Warning: using `%cx' instead of `%ecx' due to `w' suffix
+   8 ???? 660FB6C8             movzbl  %al, %cx
+****  Warning: using `%ecx' instead of `%cx' due to `l' suffix
    9                   
   10                           .code32
   11                   code32:
   12                           movsbw  %al, %ecx
   13                           movsbl  %al, %cx
   14                   
-  15 ???? 0FB6C8               movzbw  %al, %ecx
-  16 ???? 660FB6C8             movzbl  %al, %cx
+  15 ???? 660FB6C8             movzbw  %al, %ecx
+****  Warning: using `%cx' instead of `%ecx' due to `w' suffix
+  16 ???? 0FB6C8               movzbl  %al, %cx
+****  Warning: using `%ecx' instead of `%cx' due to `l' suffix
   17                   
   18                           .code64
   19                   code64:
   20                           movsbw  %al, %ecx
   21                           movsbw  %al, %rcx
   22                   
-  23 ???? 0FB6C8               movzbw  %al, %ecx
-  24 ???? 480FB6C8             movzbw  %al, %rcx
+  23                           movzbw  %al, %ecx
+  24                           movzbw  %al, %rcx
   25                   
   26                           movsbl  %al, %cx
   27                           movsbl  %al, %rcx
   28                   
-  29 ???? 660FB6C8             movzbl  %al, %cx
-  30 ???? 480FB6C8             movzbl  %al, %rcx
+  29                           movzbl  %al, %cx
+  30                           movzbl  %al, %rcx
   31                   
   32                           movsbq  %al, %cx
   33                           movsbq  %al, %ecx
   34                   
-  35 ???? 660FB6C8             movzbq  %al, %cx
-  36 ???? 0FB6C8               movzbq  %al, %ecx
+  35                           movzbq  %al, %cx
+  36                           movzbq  %al, %ecx
   37                   
   38                           movswl  %ax, %rcx
   39                           movswq  %ax, %ecx
   40                   
-  41 ???? 480FB7C8             movzwl  %ax, %rcx
-  42 ???? 0FB7C8               movzwq  %ax, %ecx
+  41                           movzwl  %ax, %rcx
+  42                           movzwq  %ax, %ecx

IOW,
- for 32- and 16-bit code generated code and emitted diagnostics get brought in
sync with that for other insns, i.e. suffix trumps register size,
- for 64-bit code emitted diagnostics get brought in sync with that for other
insns, i.e. mismatched suffix and register size are not allowed,
- for 64-bit code additionally MOVZ* behavior no longer differs from MOVS* one,
except for the precise wording of the error ("incorrect register ... used with
... suffix" vs "operand size mismatch").

Of course this example additionally demonstrates that MOVS* handling in 32- and
16-bit modes still won't be in line with all other insns, due to there not
being true suffixes in the insn templates. But that's a separate topic,
adjustment to which was previously attempted but rejected by the maintainer.

-- 
You are receiving this mail because:
You are on the CC list for the bug.