This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
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