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

Message ID c9579c40-5f3f-de90-c666-f110882cf102@suse.com
State New
Headers show
Series
  • x86: replace adhoc (partly wrong) ambiguous operand checking for MOVSX/MOVZX
Related show

Commit Message

Jan Beulich Feb. 14, 2020, 12:26 p.m.
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.	
---
v8: New, split from previous patch.

Comments

H.J. Lu Feb. 14, 2020, 12:28 p.m. | #1
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.

-- 
H.J.
Jan Beulich Feb. 14, 2020, 1:13 p.m. | #2
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.


Well, you know eagerly how people usually look at documentation.
There being an ambiguity still deserves a warning. Documentation
tells us what code to generate (and that we may not change this).
Anyway - I give up here and will maintain the patch in my
private trees. Hopefully there'll be a better time for it later
on.

Jan
Jan Beulich Feb. 14, 2020, 1:54 p.m. | #3
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
H.J. Lu Feb. 14, 2020, 2:16 p.m. | #4
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.


-- 
H.J.
Jan Beulich Feb. 14, 2020, 2:23 p.m. | #5
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
H.J. Lu Feb. 14, 2020, 2:25 p.m. | #6
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.

-- 
H.J.
Jan Beulich Feb. 14, 2020, 2:32 p.m. | #7
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.
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.

Jan
H.J. Lu Feb. 14, 2020, 2:37 p.m. | #8
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.
Jan Beulich Feb. 14, 2020, 3:47 p.m. | #9
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
Jan Beulich Feb. 14, 2020, 3:52 p.m. | #10
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.


Hmm, even worse: It's not there. Neither of the two doc changes of
yours today say anything like this. Did you forget to both post a
patch _and_ push it, or am I blind, or are you simply lying to me?
I'm sorry for being blunt, but I'm getting really annoyed.

Jan
H.J. Lu Feb. 14, 2020, 4:26 p.m. | #11
On Fri, Feb 14, 2020 at 7:52 AM Jan Beulich <jbeulich@suse.com> wrote:
>

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

>

> Hmm, even worse: It's not there. Neither of the two doc changes of

> yours today say anything like this. Did you forget to both post a

> patch _and_ push it, or am I blind, or are you simply lying to me?

> I'm sorry for being blunt, but I'm getting really annoyed.

>


info as.info on master branch shows


 The Intel-syntax extension instructions

   * 'movsx' -- sign-extend 'reg8/mem8' to 'reg16'.

   * 'movsx' -- sign-extend 'reg8/mem8' to 'reg32'.

   * 'movsx' -- sign-extend 'reg8/mem8' to 'reg64' (x86-64 only).

   * 'movsx' -- sign-extend 'reg16/mem16' to 'reg32'

   * 'movsx' -- sign-extend 'reg16/mem16' to 'reg64' (x86-64 only).

   * 'movsxd' -- sign-extend 'reg32/mem32' to 'reg64' (x86-64 only).

   * 'movzx' -- zero-extend 'reg8/mem8' to 'reg16'.

   * 'movzx' -- zero-extend 'reg8/mem8' to 'reg32'.

   * 'movzx' -- zero-extend 'reg8/mem8' to 'reg64' (x86-64 only).

   * 'movzx' -- zero-extend 'reg16/mem16' to 'reg32'

   * 'movzx' -- zero-extend 'reg16/mem16' to 'reg64' (x86-64 only).

are called 'movsbw/movsxb/movsx', 'movsbl/movsxb/movsx',
'movsbq/movsb/movsx', 'movswl/movsxw', 'movswq/movsxw', 'movslq/movsxl',
'movzbw/movzxb/movzx', 'movzbl/movzxb/movzx', 'movzbq/movzxb/movzx',
'movzwl/movzxw' and 'movzwq/movzxw' in AT&T syntax.


-- 
H.J.
Jan Beulich Feb. 14, 2020, 4:35 p.m. | #12
On 14.02.2020 17:26, H.J. Lu wrote:
> On Fri, Feb 14, 2020 at 7:52 AM Jan Beulich <jbeulich@suse.com> wrote:

>>

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

>>

>> Hmm, even worse: It's not there. Neither of the two doc changes of

>> yours today say anything like this. Did you forget to both post a

>> patch _and_ push it, or am I blind, or are you simply lying to me?

>> I'm sorry for being blunt, but I'm getting really annoyed.

>>

> 

> info as.info on master branch shows

> 

> 

>  The Intel-syntax extension instructions

> 

>    * 'movsx' -- sign-extend 'reg8/mem8' to 'reg16'.

> 

>    * 'movsx' -- sign-extend 'reg8/mem8' to 'reg32'.

> 

>    * 'movsx' -- sign-extend 'reg8/mem8' to 'reg64' (x86-64 only).

> 

>    * 'movsx' -- sign-extend 'reg16/mem16' to 'reg32'

> 

>    * 'movsx' -- sign-extend 'reg16/mem16' to 'reg64' (x86-64 only).

> 

>    * 'movsxd' -- sign-extend 'reg32/mem32' to 'reg64' (x86-64 only).

> 

>    * 'movzx' -- zero-extend 'reg8/mem8' to 'reg16'.

> 

>    * 'movzx' -- zero-extend 'reg8/mem8' to 'reg32'.

> 

>    * 'movzx' -- zero-extend 'reg8/mem8' to 'reg64' (x86-64 only).

> 

>    * 'movzx' -- zero-extend 'reg16/mem16' to 'reg32'

> 

>    * 'movzx' -- zero-extend 'reg16/mem16' to 'reg64' (x86-64 only).

> 

> are called 'movsbw/movsxb/movsx', 'movsbl/movsxb/movsx',

> 'movsbq/movsb/movsx', 'movswl/movsxw', 'movswq/movsxw', 'movslq/movsxl',

> 'movzbw/movzxb/movzx', 'movzbl/movzxb/movzx', 'movzbq/movzxb/movzx',

> 'movzwl/movzxw' and 'movzwq/movzxw' in AT&T syntax.


Which doesn't say anywhere that with a memory operand but
without suffix both default to a byte source. Yet that's the
whole point of the discussion we're having.

Jan
H.J. Lu Feb. 14, 2020, 4:51 p.m. | #13
On Fri, Feb 14, 2020 at 8:35 AM Jan Beulich <jbeulich@suse.com> wrote:
>

> On 14.02.2020 17:26, H.J. Lu wrote:

> > On Fri, Feb 14, 2020 at 7:52 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>

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

> >>

> >> Hmm, even worse: It's not there. Neither of the two doc changes of

> >> yours today say anything like this. Did you forget to both post a

> >> patch _and_ push it, or am I blind, or are you simply lying to me?

> >> I'm sorry for being blunt, but I'm getting really annoyed.

> >>

> >

> > info as.info on master branch shows

> >

> >

> >  The Intel-syntax extension instructions

> >

> >    * 'movsx' -- sign-extend 'reg8/mem8' to 'reg16'.

> >

> >    * 'movsx' -- sign-extend 'reg8/mem8' to 'reg32'.

> >

> >    * 'movsx' -- sign-extend 'reg8/mem8' to 'reg64' (x86-64 only).

> >

> >    * 'movsx' -- sign-extend 'reg16/mem16' to 'reg32'

> >

> >    * 'movsx' -- sign-extend 'reg16/mem16' to 'reg64' (x86-64 only).

> >

> >    * 'movsxd' -- sign-extend 'reg32/mem32' to 'reg64' (x86-64 only).

> >

> >    * 'movzx' -- zero-extend 'reg8/mem8' to 'reg16'.

> >

> >    * 'movzx' -- zero-extend 'reg8/mem8' to 'reg32'.

> >

> >    * 'movzx' -- zero-extend 'reg8/mem8' to 'reg64' (x86-64 only).

> >

> >    * 'movzx' -- zero-extend 'reg16/mem16' to 'reg32'

> >

> >    * 'movzx' -- zero-extend 'reg16/mem16' to 'reg64' (x86-64 only).

> >

> > are called 'movsbw/movsxb/movsx', 'movsbl/movsxb/movsx',

> > 'movsbq/movsb/movsx', 'movswl/movsxw', 'movswq/movsxw', 'movslq/movsxl',

> > 'movzbw/movzxb/movzx', 'movzbl/movzxb/movzx', 'movzbq/movzxb/movzx',

> > 'movzwl/movzxw' and 'movzwq/movzxw' in AT&T syntax.

>

> Which doesn't say anywhere that with a memory operand but

> without suffix both default to a byte source. Yet that's the

> whole point of the discussion we're having.

>


Does 'movsbw/movsxb/movsx' cover it?


-- 
H.J.
Jan Beulich Feb. 17, 2020, 1:44 p.m. | #14
On 14.02.2020 17:51, H.J. Lu wrote:
> On Fri, Feb 14, 2020 at 8:35 AM Jan Beulich <jbeulich@suse.com> wrote:

>>

>> On 14.02.2020 17:26, H.J. Lu wrote:

>>> On Fri, Feb 14, 2020 at 7:52 AM Jan Beulich <jbeulich@suse.com> wrote:

>>>>

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

>>>>

>>>> Hmm, even worse: It's not there. Neither of the two doc changes of

>>>> yours today say anything like this. Did you forget to both post a

>>>> patch _and_ push it, or am I blind, or are you simply lying to me?

>>>> I'm sorry for being blunt, but I'm getting really annoyed.

>>>>

>>>

>>> info as.info on master branch shows

>>>

>>>

>>>  The Intel-syntax extension instructions

>>>

>>>    * 'movsx' -- sign-extend 'reg8/mem8' to 'reg16'.

>>>

>>>    * 'movsx' -- sign-extend 'reg8/mem8' to 'reg32'.

>>>

>>>    * 'movsx' -- sign-extend 'reg8/mem8' to 'reg64' (x86-64 only).

>>>

>>>    * 'movsx' -- sign-extend 'reg16/mem16' to 'reg32'

>>>

>>>    * 'movsx' -- sign-extend 'reg16/mem16' to 'reg64' (x86-64 only).

>>>

>>>    * 'movsxd' -- sign-extend 'reg32/mem32' to 'reg64' (x86-64 only).

>>>

>>>    * 'movzx' -- zero-extend 'reg8/mem8' to 'reg16'.

>>>

>>>    * 'movzx' -- zero-extend 'reg8/mem8' to 'reg32'.

>>>

>>>    * 'movzx' -- zero-extend 'reg8/mem8' to 'reg64' (x86-64 only).

>>>

>>>    * 'movzx' -- zero-extend 'reg16/mem16' to 'reg32'

>>>

>>>    * 'movzx' -- zero-extend 'reg16/mem16' to 'reg64' (x86-64 only).

>>>

>>> are called 'movsbw/movsxb/movsx', 'movsbl/movsxb/movsx',

>>> 'movsbq/movsb/movsx', 'movswl/movsxw', 'movswq/movsxw', 'movslq/movsxl',

>>> 'movzbw/movzxb/movzx', 'movzbl/movzxb/movzx', 'movzbq/movzxb/movzx',

>>> 'movzwl/movzxw' and 'movzwq/movzxw' in AT&T syntax.

>>

>> Which doesn't say anywhere that with a memory operand but

>> without suffix both default to a byte source. Yet that's the

>> whole point of the discussion we're having.

>>

> 

> Does 'movsbw/movsxb/movsx' cover it?


No, it doesn't, because its companion 'movswl/movsxw' is obviously
(to me at least) incomplete, as for register operands plain "movsx"
is suitable too. It's imo wrong in the first place to formally
name any movsx* or movzx* mnemonics to be valid in AT&T syntax. As
said, the Solaris spec doesn't mention them. Hence they're at best
hybrids, which we mean to permit, but without making them legal AT&T
syntax.

Jan
H.J. Lu Feb. 17, 2020, 2:14 p.m. | #15
On Mon, Feb 17, 2020 at 5:44 AM Jan Beulich <jbeulich@suse.com> wrote:
>

> On 14.02.2020 17:51, H.J. Lu wrote:

> > On Fri, Feb 14, 2020 at 8:35 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>

> >> On 14.02.2020 17:26, H.J. Lu wrote:

> >>> On Fri, Feb 14, 2020 at 7:52 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>>>

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

> >>>>

> >>>> Hmm, even worse: It's not there. Neither of the two doc changes of

> >>>> yours today say anything like this. Did you forget to both post a

> >>>> patch _and_ push it, or am I blind, or are you simply lying to me?

> >>>> I'm sorry for being blunt, but I'm getting really annoyed.

> >>>>

> >>>

> >>> info as.info on master branch shows

> >>>

> >>>

> >>>  The Intel-syntax extension instructions

> >>>

> >>>    * 'movsx' -- sign-extend 'reg8/mem8' to 'reg16'.

> >>>

> >>>    * 'movsx' -- sign-extend 'reg8/mem8' to 'reg32'.

> >>>

> >>>    * 'movsx' -- sign-extend 'reg8/mem8' to 'reg64' (x86-64 only).

> >>>

> >>>    * 'movsx' -- sign-extend 'reg16/mem16' to 'reg32'

> >>>

> >>>    * 'movsx' -- sign-extend 'reg16/mem16' to 'reg64' (x86-64 only).

> >>>

> >>>    * 'movsxd' -- sign-extend 'reg32/mem32' to 'reg64' (x86-64 only).

> >>>

> >>>    * 'movzx' -- zero-extend 'reg8/mem8' to 'reg16'.

> >>>

> >>>    * 'movzx' -- zero-extend 'reg8/mem8' to 'reg32'.

> >>>

> >>>    * 'movzx' -- zero-extend 'reg8/mem8' to 'reg64' (x86-64 only).

> >>>

> >>>    * 'movzx' -- zero-extend 'reg16/mem16' to 'reg32'

> >>>

> >>>    * 'movzx' -- zero-extend 'reg16/mem16' to 'reg64' (x86-64 only).

> >>>

> >>> are called 'movsbw/movsxb/movsx', 'movsbl/movsxb/movsx',

> >>> 'movsbq/movsb/movsx', 'movswl/movsxw', 'movswq/movsxw', 'movslq/movsxl',

> >>> 'movzbw/movzxb/movzx', 'movzbl/movzxb/movzx', 'movzbq/movzxb/movzx',

> >>> 'movzwl/movzxw' and 'movzwq/movzxw' in AT&T syntax.

> >>

> >> Which doesn't say anywhere that with a memory operand but

> >> without suffix both default to a byte source. Yet that's the

> >> whole point of the discussion we're having.

> >>

> >

> > Does 'movsbw/movsxb/movsx' cover it?

>

> No, it doesn't, because its companion 'movswl/movsxw' is obviously

> (to me at least) incomplete, as for register operands plain "movsx"

> is suitable too. It's imo wrong in the first place to formally

> name any movsx* or movzx* mnemonics to be valid in AT&T syntax. As

> said, the Solaris spec doesn't mention them. Hence they're at best

> hybrids, which we mean to permit, but without making them legal AT&T

> syntax.


Not document movsxX/movsx is fine.  But we should just silently accept
them since assembly codes are encoded correctly.

-- 
H.J.
Jan Beulich Feb. 17, 2020, 3:37 p.m. | #16
On 17.02.2020 15:14, H.J. Lu wrote:
> On Mon, Feb 17, 2020 at 5:44 AM Jan Beulich <jbeulich@suse.com> wrote:

>>

>> On 14.02.2020 17:51, H.J. Lu wrote:

>>> On Fri, Feb 14, 2020 at 8:35 AM Jan Beulich <jbeulich@suse.com> wrote:

>>>>

>>>> On 14.02.2020 17:26, H.J. Lu wrote:

>>>>> On Fri, Feb 14, 2020 at 7:52 AM Jan Beulich <jbeulich@suse.com> wrote:

>>>>>>

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

>>>>>>

>>>>>> Hmm, even worse: It's not there. Neither of the two doc changes of

>>>>>> yours today say anything like this. Did you forget to both post a

>>>>>> patch _and_ push it, or am I blind, or are you simply lying to me?

>>>>>> I'm sorry for being blunt, but I'm getting really annoyed.

>>>>>>

>>>>>

>>>>> info as.info on master branch shows

>>>>>

>>>>>

>>>>>  The Intel-syntax extension instructions

>>>>>

>>>>>    * 'movsx' -- sign-extend 'reg8/mem8' to 'reg16'.

>>>>>

>>>>>    * 'movsx' -- sign-extend 'reg8/mem8' to 'reg32'.

>>>>>

>>>>>    * 'movsx' -- sign-extend 'reg8/mem8' to 'reg64' (x86-64 only).

>>>>>

>>>>>    * 'movsx' -- sign-extend 'reg16/mem16' to 'reg32'

>>>>>

>>>>>    * 'movsx' -- sign-extend 'reg16/mem16' to 'reg64' (x86-64 only).

>>>>>

>>>>>    * 'movsxd' -- sign-extend 'reg32/mem32' to 'reg64' (x86-64 only).

>>>>>

>>>>>    * 'movzx' -- zero-extend 'reg8/mem8' to 'reg16'.

>>>>>

>>>>>    * 'movzx' -- zero-extend 'reg8/mem8' to 'reg32'.

>>>>>

>>>>>    * 'movzx' -- zero-extend 'reg8/mem8' to 'reg64' (x86-64 only).

>>>>>

>>>>>    * 'movzx' -- zero-extend 'reg16/mem16' to 'reg32'

>>>>>

>>>>>    * 'movzx' -- zero-extend 'reg16/mem16' to 'reg64' (x86-64 only).

>>>>>

>>>>> are called 'movsbw/movsxb/movsx', 'movsbl/movsxb/movsx',

>>>>> 'movsbq/movsb/movsx', 'movswl/movsxw', 'movswq/movsxw', 'movslq/movsxl',

>>>>> 'movzbw/movzxb/movzx', 'movzbl/movzxb/movzx', 'movzbq/movzxb/movzx',

>>>>> 'movzwl/movzxw' and 'movzwq/movzxw' in AT&T syntax.

>>>>

>>>> Which doesn't say anywhere that with a memory operand but

>>>> without suffix both default to a byte source. Yet that's the

>>>> whole point of the discussion we're having.

>>>>

>>>

>>> Does 'movsbw/movsxb/movsx' cover it?

>>

>> No, it doesn't, because its companion 'movswl/movsxw' is obviously

>> (to me at least) incomplete, as for register operands plain "movsx"

>> is suitable too. It's imo wrong in the first place to formally

>> name any movsx* or movzx* mnemonics to be valid in AT&T syntax. As

>> said, the Solaris spec doesn't mention them. Hence they're at best

>> hybrids, which we mean to permit, but without making them legal AT&T

>> syntax.

> 

> Not document movsxX/movsx is fine.  But we should just silently accept

> them since assembly codes are encoded correctly.


We should accept them, yes, _but not silently_. Even less so without
it being written down anywhere that this is the behavior to expect.

Jan
H.J. Lu Feb. 17, 2020, 4:55 p.m. | #17
On Mon, Feb 17, 2020 at 7:37 AM Jan Beulich <jbeulich@suse.com> wrote:
>

> On 17.02.2020 15:14, H.J. Lu wrote:

> > On Mon, Feb 17, 2020 at 5:44 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>

> >> On 14.02.2020 17:51, H.J. Lu wrote:

> >>> On Fri, Feb 14, 2020 at 8:35 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>>>

> >>>> On 14.02.2020 17:26, H.J. Lu wrote:

> >>>>> On Fri, Feb 14, 2020 at 7:52 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>>>>>

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

> >>>>>>

> >>>>>> Hmm, even worse: It's not there. Neither of the two doc changes of

> >>>>>> yours today say anything like this. Did you forget to both post a

> >>>>>> patch _and_ push it, or am I blind, or are you simply lying to me?

> >>>>>> I'm sorry for being blunt, but I'm getting really annoyed.

> >>>>>>

> >>>>>

> >>>>> info as.info on master branch shows

> >>>>>

> >>>>>

> >>>>>  The Intel-syntax extension instructions

> >>>>>

> >>>>>    * 'movsx' -- sign-extend 'reg8/mem8' to 'reg16'.

> >>>>>

> >>>>>    * 'movsx' -- sign-extend 'reg8/mem8' to 'reg32'.

> >>>>>

> >>>>>    * 'movsx' -- sign-extend 'reg8/mem8' to 'reg64' (x86-64 only).

> >>>>>

> >>>>>    * 'movsx' -- sign-extend 'reg16/mem16' to 'reg32'

> >>>>>

> >>>>>    * 'movsx' -- sign-extend 'reg16/mem16' to 'reg64' (x86-64 only).

> >>>>>

> >>>>>    * 'movsxd' -- sign-extend 'reg32/mem32' to 'reg64' (x86-64 only).

> >>>>>

> >>>>>    * 'movzx' -- zero-extend 'reg8/mem8' to 'reg16'.

> >>>>>

> >>>>>    * 'movzx' -- zero-extend 'reg8/mem8' to 'reg32'.

> >>>>>

> >>>>>    * 'movzx' -- zero-extend 'reg8/mem8' to 'reg64' (x86-64 only).

> >>>>>

> >>>>>    * 'movzx' -- zero-extend 'reg16/mem16' to 'reg32'

> >>>>>

> >>>>>    * 'movzx' -- zero-extend 'reg16/mem16' to 'reg64' (x86-64 only).

> >>>>>

> >>>>> are called 'movsbw/movsxb/movsx', 'movsbl/movsxb/movsx',

> >>>>> 'movsbq/movsb/movsx', 'movswl/movsxw', 'movswq/movsxw', 'movslq/movsxl',

> >>>>> 'movzbw/movzxb/movzx', 'movzbl/movzxb/movzx', 'movzbq/movzxb/movzx',

> >>>>> 'movzwl/movzxw' and 'movzwq/movzxw' in AT&T syntax.

> >>>>

> >>>> Which doesn't say anywhere that with a memory operand but

> >>>> without suffix both default to a byte source. Yet that's the

> >>>> whole point of the discussion we're having.

> >>>>

> >>>

> >>> Does 'movsbw/movsxb/movsx' cover it?

> >>

> >> No, it doesn't, because its companion 'movswl/movsxw' is obviously

> >> (to me at least) incomplete, as for register operands plain "movsx"

> >> is suitable too. It's imo wrong in the first place to formally

> >> name any movsx* or movzx* mnemonics to be valid in AT&T syntax. As

> >> said, the Solaris spec doesn't mention them. Hence they're at best

> >> hybrids, which we mean to permit, but without making them legal AT&T

> >> syntax.

> >

> > Not document movsxX/movsx is fine.  But we should just silently accept

> > them since assembly codes are encoded correctly.

>

> We should accept them, yes, _but not silently_. Even less so without

> it being written down anywhere that this is the behavior to expect.


Please submit a patch to improve gas manual to document such.

-- 
H.J.
Jan Beulich Feb. 17, 2020, 5:04 p.m. | #18
On 17.02.2020 17:55, H.J. Lu wrote:
> On Mon, Feb 17, 2020 at 7:37 AM Jan Beulich <jbeulich@suse.com> wrote:

>>

>> On 17.02.2020 15:14, H.J. Lu wrote:

>>> On Mon, Feb 17, 2020 at 5:44 AM Jan Beulich <jbeulich@suse.com> wrote:

>>>>

>>>> On 14.02.2020 17:51, H.J. Lu wrote:

>>>>> On Fri, Feb 14, 2020 at 8:35 AM Jan Beulich <jbeulich@suse.com> wrote:

>>>>>>

>>>>>> On 14.02.2020 17:26, H.J. Lu wrote:

>>>>>>> On Fri, Feb 14, 2020 at 7:52 AM Jan Beulich <jbeulich@suse.com> wrote:

>>>>>>>>

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

>>>>>>>>

>>>>>>>> Hmm, even worse: It's not there. Neither of the two doc changes of

>>>>>>>> yours today say anything like this. Did you forget to both post a

>>>>>>>> patch _and_ push it, or am I blind, or are you simply lying to me?

>>>>>>>> I'm sorry for being blunt, but I'm getting really annoyed.

>>>>>>>>

>>>>>>>

>>>>>>> info as.info on master branch shows

>>>>>>>

>>>>>>>

>>>>>>>  The Intel-syntax extension instructions

>>>>>>>

>>>>>>>    * 'movsx' -- sign-extend 'reg8/mem8' to 'reg16'.

>>>>>>>

>>>>>>>    * 'movsx' -- sign-extend 'reg8/mem8' to 'reg32'.

>>>>>>>

>>>>>>>    * 'movsx' -- sign-extend 'reg8/mem8' to 'reg64' (x86-64 only).

>>>>>>>

>>>>>>>    * 'movsx' -- sign-extend 'reg16/mem16' to 'reg32'

>>>>>>>

>>>>>>>    * 'movsx' -- sign-extend 'reg16/mem16' to 'reg64' (x86-64 only).

>>>>>>>

>>>>>>>    * 'movsxd' -- sign-extend 'reg32/mem32' to 'reg64' (x86-64 only).

>>>>>>>

>>>>>>>    * 'movzx' -- zero-extend 'reg8/mem8' to 'reg16'.

>>>>>>>

>>>>>>>    * 'movzx' -- zero-extend 'reg8/mem8' to 'reg32'.

>>>>>>>

>>>>>>>    * 'movzx' -- zero-extend 'reg8/mem8' to 'reg64' (x86-64 only).

>>>>>>>

>>>>>>>    * 'movzx' -- zero-extend 'reg16/mem16' to 'reg32'

>>>>>>>

>>>>>>>    * 'movzx' -- zero-extend 'reg16/mem16' to 'reg64' (x86-64 only).

>>>>>>>

>>>>>>> are called 'movsbw/movsxb/movsx', 'movsbl/movsxb/movsx',

>>>>>>> 'movsbq/movsb/movsx', 'movswl/movsxw', 'movswq/movsxw', 'movslq/movsxl',

>>>>>>> 'movzbw/movzxb/movzx', 'movzbl/movzxb/movzx', 'movzbq/movzxb/movzx',

>>>>>>> 'movzwl/movzxw' and 'movzwq/movzxw' in AT&T syntax.

>>>>>>

>>>>>> Which doesn't say anywhere that with a memory operand but

>>>>>> without suffix both default to a byte source. Yet that's the

>>>>>> whole point of the discussion we're having.

>>>>>>

>>>>>

>>>>> Does 'movsbw/movsxb/movsx' cover it?

>>>>

>>>> No, it doesn't, because its companion 'movswl/movsxw' is obviously

>>>> (to me at least) incomplete, as for register operands plain "movsx"

>>>> is suitable too. It's imo wrong in the first place to formally

>>>> name any movsx* or movzx* mnemonics to be valid in AT&T syntax. As

>>>> said, the Solaris spec doesn't mention them. Hence they're at best

>>>> hybrids, which we mean to permit, but without making them legal AT&T

>>>> syntax.

>>>

>>> Not document movsxX/movsx is fine.  But we should just silently accept

>>> them since assembly codes are encoded correctly.

>>

>> We should accept them, yes, _but not silently_. Even less so without

>> it being written down anywhere that this is the behavior to expect.

> 

> Please submit a patch to improve gas manual to document such.


Just like on the other thread - I'm not going to document what I
believe is wrong behavior. If I am to add documentation here, I'd
add it such that afterwards the implementation will need bringing
in sync. Also, let's not forget - you objected to a code change
mine on the basis that the way you wanted it is documented
_somewhere_. And now you ask _me_ to add this documentation?

Jan
H.J. Lu Feb. 17, 2020, 5:18 p.m. | #19
On Mon, Feb 17, 2020 at 9:04 AM Jan Beulich <jbeulich@suse.com> wrote:
>

> On 17.02.2020 17:55, H.J. Lu wrote:

> > On Mon, Feb 17, 2020 at 7:37 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>

> >> On 17.02.2020 15:14, H.J. Lu wrote:

> >>> On Mon, Feb 17, 2020 at 5:44 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>>>

> >>>> On 14.02.2020 17:51, H.J. Lu wrote:

> >>>>> On Fri, Feb 14, 2020 at 8:35 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>>>>>

> >>>>>> On 14.02.2020 17:26, H.J. Lu wrote:

> >>>>>>> On Fri, Feb 14, 2020 at 7:52 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>>>>>>>

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

> >>>>>>>>

> >>>>>>>> Hmm, even worse: It's not there. Neither of the two doc changes of

> >>>>>>>> yours today say anything like this. Did you forget to both post a

> >>>>>>>> patch _and_ push it, or am I blind, or are you simply lying to me?

> >>>>>>>> I'm sorry for being blunt, but I'm getting really annoyed.

> >>>>>>>>

> >>>>>>>

> >>>>>>> info as.info on master branch shows

> >>>>>>>

> >>>>>>>

> >>>>>>>  The Intel-syntax extension instructions

> >>>>>>>

> >>>>>>>    * 'movsx' -- sign-extend 'reg8/mem8' to 'reg16'.

> >>>>>>>

> >>>>>>>    * 'movsx' -- sign-extend 'reg8/mem8' to 'reg32'.

> >>>>>>>

> >>>>>>>    * 'movsx' -- sign-extend 'reg8/mem8' to 'reg64' (x86-64 only).

> >>>>>>>

> >>>>>>>    * 'movsx' -- sign-extend 'reg16/mem16' to 'reg32'

> >>>>>>>

> >>>>>>>    * 'movsx' -- sign-extend 'reg16/mem16' to 'reg64' (x86-64 only).

> >>>>>>>

> >>>>>>>    * 'movsxd' -- sign-extend 'reg32/mem32' to 'reg64' (x86-64 only).

> >>>>>>>

> >>>>>>>    * 'movzx' -- zero-extend 'reg8/mem8' to 'reg16'.

> >>>>>>>

> >>>>>>>    * 'movzx' -- zero-extend 'reg8/mem8' to 'reg32'.

> >>>>>>>

> >>>>>>>    * 'movzx' -- zero-extend 'reg8/mem8' to 'reg64' (x86-64 only).

> >>>>>>>

> >>>>>>>    * 'movzx' -- zero-extend 'reg16/mem16' to 'reg32'

> >>>>>>>

> >>>>>>>    * 'movzx' -- zero-extend 'reg16/mem16' to 'reg64' (x86-64 only).

> >>>>>>>

> >>>>>>> are called 'movsbw/movsxb/movsx', 'movsbl/movsxb/movsx',

> >>>>>>> 'movsbq/movsb/movsx', 'movswl/movsxw', 'movswq/movsxw', 'movslq/movsxl',

> >>>>>>> 'movzbw/movzxb/movzx', 'movzbl/movzxb/movzx', 'movzbq/movzxb/movzx',

> >>>>>>> 'movzwl/movzxw' and 'movzwq/movzxw' in AT&T syntax.

> >>>>>>

> >>>>>> Which doesn't say anywhere that with a memory operand but

> >>>>>> without suffix both default to a byte source. Yet that's the

> >>>>>> whole point of the discussion we're having.

> >>>>>>

> >>>>>

> >>>>> Does 'movsbw/movsxb/movsx' cover it?

> >>>>

> >>>> No, it doesn't, because its companion 'movswl/movsxw' is obviously

> >>>> (to me at least) incomplete, as for register operands plain "movsx"

> >>>> is suitable too. It's imo wrong in the first place to formally

> >>>> name any movsx* or movzx* mnemonics to be valid in AT&T syntax. As

> >>>> said, the Solaris spec doesn't mention them. Hence they're at best

> >>>> hybrids, which we mean to permit, but without making them legal AT&T

> >>>> syntax.

> >>>

> >>> Not document movsxX/movsx is fine.  But we should just silently accept

> >>> them since assembly codes are encoded correctly.

> >>

> >> We should accept them, yes, _but not silently_. Even less so without

> >> it being written down anywhere that this is the behavior to expect.

> >

> > Please submit a patch to improve gas manual to document such.

>

> Just like on the other thread - I'm not going to document what I

> believe is wrong behavior. If I am to add documentation here, I'd

> add it such that afterwards the implementation will need bringing

> in sync. Also, let's not forget - you objected to a code change

> mine on the basis that the way you wanted it is documented

> _somewhere_. And now you ask _me_ to add this documentation?


I did add documentation.

-- 
H.J.
Jan Beulich Feb. 18, 2020, 7:44 a.m. | #20
On 17.02.2020 18:18, H.J. Lu wrote:
> On Mon, Feb 17, 2020 at 9:04 AM Jan Beulich <jbeulich@suse.com> wrote:

>>

>> On 17.02.2020 17:55, H.J. Lu wrote:

>>> On Mon, Feb 17, 2020 at 7:37 AM Jan Beulich <jbeulich@suse.com> wrote:

>>>>

>>>> On 17.02.2020 15:14, H.J. Lu wrote:

>>>>> On Mon, Feb 17, 2020 at 5:44 AM Jan Beulich <jbeulich@suse.com> wrote:

>>>>>>

>>>>>> On 14.02.2020 17:51, H.J. Lu wrote:

>>>>>>> On Fri, Feb 14, 2020 at 8:35 AM Jan Beulich <jbeulich@suse.com> wrote:

>>>>>>>>

>>>>>>>> On 14.02.2020 17:26, H.J. Lu wrote:

>>>>>>>>> On Fri, Feb 14, 2020 at 7:52 AM Jan Beulich <jbeulich@suse.com> wrote:

>>>>>>>>>>

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

>>>>>>>>>>

>>>>>>>>>> Hmm, even worse: It's not there. Neither of the two doc changes of

>>>>>>>>>> yours today say anything like this. Did you forget to both post a

>>>>>>>>>> patch _and_ push it, or am I blind, or are you simply lying to me?

>>>>>>>>>> I'm sorry for being blunt, but I'm getting really annoyed.

>>>>>>>>>>

>>>>>>>>>

>>>>>>>>> info as.info on master branch shows

>>>>>>>>>

>>>>>>>>>

>>>>>>>>>  The Intel-syntax extension instructions

>>>>>>>>>

>>>>>>>>>    * 'movsx' -- sign-extend 'reg8/mem8' to 'reg16'.

>>>>>>>>>

>>>>>>>>>    * 'movsx' -- sign-extend 'reg8/mem8' to 'reg32'.

>>>>>>>>>

>>>>>>>>>    * 'movsx' -- sign-extend 'reg8/mem8' to 'reg64' (x86-64 only).

>>>>>>>>>

>>>>>>>>>    * 'movsx' -- sign-extend 'reg16/mem16' to 'reg32'

>>>>>>>>>

>>>>>>>>>    * 'movsx' -- sign-extend 'reg16/mem16' to 'reg64' (x86-64 only).

>>>>>>>>>

>>>>>>>>>    * 'movsxd' -- sign-extend 'reg32/mem32' to 'reg64' (x86-64 only).

>>>>>>>>>

>>>>>>>>>    * 'movzx' -- zero-extend 'reg8/mem8' to 'reg16'.

>>>>>>>>>

>>>>>>>>>    * 'movzx' -- zero-extend 'reg8/mem8' to 'reg32'.

>>>>>>>>>

>>>>>>>>>    * 'movzx' -- zero-extend 'reg8/mem8' to 'reg64' (x86-64 only).

>>>>>>>>>

>>>>>>>>>    * 'movzx' -- zero-extend 'reg16/mem16' to 'reg32'

>>>>>>>>>

>>>>>>>>>    * 'movzx' -- zero-extend 'reg16/mem16' to 'reg64' (x86-64 only).

>>>>>>>>>

>>>>>>>>> are called 'movsbw/movsxb/movsx', 'movsbl/movsxb/movsx',

>>>>>>>>> 'movsbq/movsb/movsx', 'movswl/movsxw', 'movswq/movsxw', 'movslq/movsxl',

>>>>>>>>> 'movzbw/movzxb/movzx', 'movzbl/movzxb/movzx', 'movzbq/movzxb/movzx',

>>>>>>>>> 'movzwl/movzxw' and 'movzwq/movzxw' in AT&T syntax.

>>>>>>>>

>>>>>>>> Which doesn't say anywhere that with a memory operand but

>>>>>>>> without suffix both default to a byte source. Yet that's the

>>>>>>>> whole point of the discussion we're having.

>>>>>>>>

>>>>>>>

>>>>>>> Does 'movsbw/movsxb/movsx' cover it?

>>>>>>

>>>>>> No, it doesn't, because its companion 'movswl/movsxw' is obviously

>>>>>> (to me at least) incomplete, as for register operands plain "movsx"

>>>>>> is suitable too. It's imo wrong in the first place to formally

>>>>>> name any movsx* or movzx* mnemonics to be valid in AT&T syntax. As

>>>>>> said, the Solaris spec doesn't mention them. Hence they're at best

>>>>>> hybrids, which we mean to permit, but without making them legal AT&T

>>>>>> syntax.

>>>>>

>>>>> Not document movsxX/movsx is fine.  But we should just silently accept

>>>>> them since assembly codes are encoded correctly.

>>>>

>>>> We should accept them, yes, _but not silently_. Even less so without

>>>> it being written down anywhere that this is the behavior to expect.

>>>

>>> Please submit a patch to improve gas manual to document such.

>>

>> Just like on the other thread - I'm not going to document what I

>> believe is wrong behavior. If I am to add documentation here, I'd

>> add it such that afterwards the implementation will need bringing

>> in sync. Also, let's not forget - you objected to a code change

>> mine on the basis that the way you wanted it is documented

>> _somewhere_. And now you ask _me_ to add this documentation?

> 

> I did add documentation.


You mean the part still quoted above? As you were able to see, even
being aware of the context I couldn't interpret it as even coming
close to what you meant to document. It does in no way support your
claim of there being a defaulting to byte source. (And of course it
also continues to be the case that you claimed such documentation
was in place _before_ you actually added this piece.) I don't think
I'm in the slightest convinced that suppressing the warning in this
particular case is warranted. In fact the process of the discussion
has convinced me even further that a warning _is needed_ (and not
just warranted) here.

Jan

Patch

--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -6335,10 +6335,11 @@  process_suffix (void)
 		break;
 	      }
 
-	  /* As an exception, movsx/movzx silently default to a byte source
-	     in AT&T mode.  */
+	  /* As an exception, movsx/movzx with a word register destination
+	     silently default to a byte source in AT&T mode, as their word
+	     memory source case isn't really useful.  */
 	  if ((i.tm.base_opcode | 8) == 0xfbe && i.tm.opcode_modifier.w
-	      && !i.suffix && !intel_syntax)
+	      && !i.suffix && !intel_syntax && i.types[1].bitfield.word)
 	    i.suffix = BYTE_MNEM_SUFFIX;
 	}
       else if (i.suffix == BYTE_MNEM_SUFFIX)
--- a/gas/testsuite/gas/i386/noreg16.l
+++ b/gas/testsuite/gas/i386/noreg16.l
@@ -56,6 +56,8 @@ 
 .*:[1-9][0-9]*: Warning: .* `mov'
 .*:[1-9][0-9]*: Warning: .* `movs'
 .*:[1-9][0-9]*: Warning: .* `movs'
+.*:[1-9][0-9]*: Warning: .* `movsx'
+.*:[1-9][0-9]*: Warning: .* `movzx'
 .*:[1-9][0-9]*: Warning: .* `mul'
 .*:[1-9][0-9]*: Warning: .* `neg'
 .*:[1-9][0-9]*: Warning: .* `nop'
--- a/gas/testsuite/gas/i386/noreg32.l
+++ b/gas/testsuite/gas/i386/noreg32.l
@@ -61,6 +61,8 @@ 
 .*:[1-9][0-9]*: Warning: .* `mov'
 .*:[1-9][0-9]*: Warning: .* `movs'
 .*:[1-9][0-9]*: Warning: .* `movs'
+.*:[1-9][0-9]*: Warning: .* `movsx'
+.*:[1-9][0-9]*: Warning: .* `movzx'
 .*:[1-9][0-9]*: Warning: .* `mul'
 .*:[1-9][0-9]*: Warning: .* `neg'
 .*:[1-9][0-9]*: Warning: .* `nop'
--- a/gas/testsuite/gas/i386/noreg64.l
+++ b/gas/testsuite/gas/i386/noreg64.l
@@ -67,6 +67,10 @@ 
 .*:[1-9][0-9]*: Warning: .* `mov'
 .*:[1-9][0-9]*: Warning: .* `movs'
 .*:[1-9][0-9]*: Warning: .* `movs'
+.*:[1-9][0-9]*: Warning: .* `movsx'
+.*:[1-9][0-9]*: Warning: .* `movsx'
+.*:[1-9][0-9]*: Warning: .* `movzx'
+.*:[1-9][0-9]*: Warning: .* `movzx'
 .*:[1-9][0-9]*: Warning: .* `mul'
 .*:[1-9][0-9]*: Warning: .* `neg'
 .*:[1-9][0-9]*: Warning: .* `nop'