https://sourceware.org/bugzilla/show_bug.cgi?id=25445
--- Comment #5 from Jan Beulich <jbeulich at suse dot com> --- (In reply to H.J. Lu from comment #4) > (In reply to Jan Beulich from comment #3) > > (In reply to H.J. Lu from comment #0) > > > 0: 66 63 08 movslq (%rax),%cx > > > > Looks correct to me. > > movslq is AT&T syntax for 32 bits -> 64 bits. It isn't accepted by > assembler. movsxd should be here. MOVSXD, like MOVSX and MOVZX, is Intel syntax, and hence has nothing to do in AT&T syntax disassembly. > > (In reply to H.J. Lu from comment #1) > > > Also > > > > > > 63 08 movslq (%rax),%ecx > > > > This too looks correct to me. > > movsxd should be here. Same here. > > The only anomaly I can think of because of the vendor difference would be a > > memory operand in Intel syntax mode, which - if tagged by an operand size - > > might want to be WORD PTR for the 16-bit case in Intel64 mode and DWORD PTR > > in the AMD64 one. > > Manual can be wrong. The current Intel manual says that MOVSXD is valid > for 32-bit. Can you double check MOVSXD on AMD processor to verify > > movsxd (%rax), %cx > > does load 4 bytes? I did already around the time I put together https://sourceware.org/ml/binutils/2019-12/msg00347.html Both manuals accurately describe actual hardware behavior. -- You are receiving this mail because: You are on the CC list for the bug.
