From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130479 invoked by alias); 14 Feb 2020 14:38:17 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 130470 invoked by uid 89); 14 Feb 2020 14:38:17 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:36f5125, HX-Received:sk:d67mr20, H*i:sk:36f5125, H*RU:209.85.167.195 X-HELO: mail-oi1-f195.google.com Received: from mail-oi1-f195.google.com (HELO mail-oi1-f195.google.com) (209.85.167.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 14 Feb 2020 14:38:15 +0000 Received: by mail-oi1-f195.google.com with SMTP id a142so9578066oii.7 for ; Fri, 14 Feb 2020 06:38:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VC5dG+SCWlRHvWo1atpZrATWivHhCd+p0dBtYFR0MAo=; b=eXKvlBqS/Du4egulQiFpl+9b1f/q8zq+4DDMrr8/3x/weObJhUEyeptGXPaFGAsylU O3CHjSLtX8fW+dXRfJI+2GwUjGLV8Vp4uIj2rBj/rpNg1sdbSLajz+GHc8GCAPrrMpjq jQNY0+PcSds/Mohf8Yfh1wzVFdCAQ7InHbnSJCrRN+oJOspmVb+6H0+oqnZuiz9g6Crt 7q5lKi32fA53nVt038izpwm+YS15GuNrm1GkjiXq8SHgnD9O6UCyhFiYqO602nOSig51 K71QtE2otnYfSqNiqy/tvybB1H0kFMuHPlzNECtJRXfZNcXBQdLT/S+f98iwkThIwGkr kVOw== MIME-Version: 1.0 References: <92fd2cf8-90a0-98f8-9453-c49d911daec6@suse.com> <84508928-4fdb-997f-b187-66ea614fd9bc@suse.com> <36f5125e-6aa8-168c-8efe-032029a4fcbe@suse.com> In-Reply-To: <36f5125e-6aa8-168c-8efe-032029a4fcbe@suse.com> From: "H.J. Lu" Date: Fri, 14 Feb 2020 14:38:00 -0000 Message-ID: Subject: Re: [PATCH v8 2/2] x86/AT&T: don't default to byte source for ambiguous for MOVSX/MOVZX To: Jan Beulich Cc: "binutils@sourceware.org" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00362.txt.bz2 On Fri, Feb 14, 2020 at 6:32 AM Jan Beulich wrote: > > On 14.02.2020 15:25, H.J. Lu wrote: > > On Fri, Feb 14, 2020 at 6:23 AM Jan Beulich wrote: > >> > >> On 14.02.2020 15:16, H.J. Lu wrote: > >>> On Fri, Feb 14, 2020 at 5:54 AM Jan Beulich wrote: > >>>> > >>>> On 14.02.2020 13:28, H.J. Lu wrote: > >>>>> On Fri, Feb 14, 2020 at 4:26 AM Jan Beulich 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 > >>>>>> > >>>>>> 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.