[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 14:23:00 GMT 2020


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



More information about the Binutils mailing list