Re: [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX

["H.J. Lu" <hjl.tools@gmail.com>]

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.

> 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?

-- 
H.J.