[PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
Jan Beulich
jbeulich@suse.com
Fri Feb 14 13:54:00 GMT 2020
More information about the Binutils mailing list
Fri Feb 14 13:54:00 GMT 2020
- Previous message (by thread): [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
- Next message (by thread): [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
- Next message (by thread): [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Binutils mailing list