From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60430 invoked by alias); 12 Feb 2020 09:19:07 -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 60417 invoked by uid 89); 12 Feb 2020 09:19:06 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.5 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,SPF_PASS autolearn=ham version=3.3.1 spammy=picture, HX-Languages-Length:2202 X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Feb 2020 09:19:05 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id F2BF3AB98; Wed, 12 Feb 2020 09:19:02 +0000 (UTC) Subject: Re: [PATCH] x86: Remove movsx/movzx with 16/32-bit memory operand from AT&T syntax To: "H.J. Lu" References: <891e9e3a-0e39-b3fd-a06a-d89bedaa8ec1@suse.com> <416bb4a2-c02f-7591-7aa1-55874844fc39@suse.com> <20200212031924.GA2551231@gmail.com> From: Jan Beulich Cc: "binutils@sourceware.org" Message-ID: Date: Wed, 12 Feb 2020 09:19:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <20200212031924.GA2551231@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00205.txt.bz2 On 12.02.2020 04:19, H.J. Lu wrote: > AT&T syntax requires suffix to specify memory operand size. Since > movsx and movzx can have different memory operand sizes with the same > destination register, this patch removes movsx and movzx with 16/32-bit > memory operand from AT&T syntax. Now movzx and movsx with incorrect > suffix and register are error in AT&T syntax. Before we discuss this patch in detail, I think we need to come to an agreement what is and what is not meant to be permitted. My position of this is shown by the final shape of the new tests that the series at the root of this thread first adds and then adjusts. It was for this very reason why I had asked that you please point out specifically against the two patches you put under question what you think is wrong once those patches would be in place. What you say above makes no sense to me at all: Why would you remove support for something that's supposed to work? You know my underlying thinking - things should be as consistent as possible. What you do here moves us farther away from consistency. This is demonstrated by both increasing the number of templates (whereas my proposed patch shrinks them) as well as ... > --- a/gas/config/tc-i386.c > +++ b/gas/config/tc-i386.c > @@ -4395,7 +4395,9 @@ md_assemble (char *line) > && intel_syntax) > as_bad (_("ambiguous operand size for `%s'"), i.tm.name); > > - i.suffix = 0; > + /* movzx and movsx only allow the 'b' suffix in AT&T syntax. */ > + if (i.suffix == BYTE_MNEM_SUFFIX || intel_syntax) > + i.suffix = 0; > } ... a change like this. Recall that mine does away with this rather arbitrary check here altogether, putting in place less arbitrary (imo) checks/adjustments elsewhere instead? While secondary, I also get the impression that, other than my patch again, and in contrast to the adjustments recently done for MOVSXD, the (not very useful) form having 16-bit source and destination doesn't get supported by this change. Which underlines what I've said initially: There first of all needs to be a clear (and consistent) picture of what is or is not supposed to work. Jan