From: "H.J. Lu" <hjl.tools@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "binutils@sourceware.org" <binutils@sourceware.org>
Subject: Re: [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX
Date: Fri, 14 Feb 2020 14:16:00 -0000 [thread overview]
Message-ID: <CAMe9rOoFKF-BCriXp3hYWtUxFZa6Snc4MR9McHuB=fySYpQLdQ@mail.gmail.com> (raw)
In-Reply-To: <84508928-4fdb-997f-b187-66ea614fd9bc@suse.com>
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.
next prev parent reply other threads:[~2020-02-14 14:16 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-14 12:21 [PATCH v8 0/2] x86: replace adhoc (partly wrong) ambiguous operand checking " Jan Beulich
2020-02-14 12:26 ` [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous " Jan Beulich
2020-02-14 12:28 ` H.J. Lu
2020-02-14 13:13 ` Jan Beulich
2020-02-14 13:54 ` Jan Beulich
2020-02-14 14:16 ` H.J. Lu [this message]
2020-02-14 14:23 ` Jan Beulich
2020-02-14 14:26 ` H.J. Lu
2020-02-14 14:32 ` Jan Beulich
2020-02-14 14:38 ` H.J. Lu
2020-02-14 15:47 ` Jan Beulich
2020-02-14 15:52 ` Jan Beulich
2020-02-14 16:26 ` H.J. Lu
2020-02-14 16:36 ` Jan Beulich
2020-02-14 16:52 ` H.J. Lu
2020-02-17 13:44 ` Jan Beulich
2020-02-17 14:14 ` H.J. Lu
2020-02-17 15:37 ` Jan Beulich
2020-02-17 16:56 ` H.J. Lu
2020-02-17 17:04 ` Jan Beulich
2020-02-17 17:19 ` H.J. Lu
2020-02-18 7:44 ` Jan Beulich
2020-02-14 12:26 ` [PATCH v8 1/2] x86: replace adhoc (partly wrong) ambiguous operand checking " Jan Beulich
2020-02-14 12:31 ` H.J. Lu
2020-02-14 12:34 ` H.J. Lu
2020-02-14 12:42 ` Jan Beulich
2020-02-14 12:49 ` H.J. Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMe9rOoFKF-BCriXp3hYWtUxFZa6Snc4MR9McHuB=fySYpQLdQ@mail.gmail.com' \
--to=hjl.tools@gmail.com \
--cc=binutils@sourceware.org \
--cc=jbeulich@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).