From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10217 invoked by alias); 11 Feb 2020 13:02:27 -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 10208 invoked by uid 89); 11 Feb 2020 13:02:26 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:891e9e3, H*f:sk:891e9e3 X-HELO: mail-ot1-f65.google.com Received: from mail-ot1-f65.google.com (HELO mail-ot1-f65.google.com) (209.85.210.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 11 Feb 2020 13:02:25 +0000 Received: by mail-ot1-f65.google.com with SMTP id 66so9942206otd.9 for ; Tue, 11 Feb 2020 05:02:25 -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=POvsyiHgZaApzDiQXMZ+Ibqw4N9Ha5hz6CGQVIDYzNs=; b=RsvrpI5VsZy297UR0UdY48ROURqPRFBKvJbQC34Pe/cCU1eoRVwlDzyaM1w/utvW6a 5IcREZ870q/MPyDWW//gtI5oWEddMdVJtoKdYhvJYgGcpakMHD4D0iAddLl1cvt6W2Zw MEzHERBqx2KY/xOTbyM3+7KSylL8g5NLwpkJ5z/FcaXfztxMwKV+0WfAqIVUlDJV7RfW udZ0Lc6Dysz4kmGAWoz8m1Fccxy36Ci6nkD5d4l5Pp660VOpnyKp8qD9wrAoufEnr7+s e3Fc8N30eWRWK0ZuDntLQadlq8NxYtFfZ+iZGOOlp47toSV+AsxuGOGBjHSMwDGhQsQt YAJw== MIME-Version: 1.0 References: <1e1b8eba-93ff-39ed-460a-a922d12af27e@suse.com> <74b85fa8-3b1a-d673-d26e-7baaadc69ee6@suse.com> <17a5be6c-a904-1405-5be1-cc4987b7d024@suse.com> <891e9e3a-0e39-b3fd-a06a-d89bedaa8ec1@suse.com> In-Reply-To: <891e9e3a-0e39-b3fd-a06a-d89bedaa8ec1@suse.com> From: "H.J. Lu" Date: Tue, 11 Feb 2020 13:02:00 -0000 Message-ID: Subject: Re: [PATCH v5 2/5] x86: move certain MOVSX/MOVZX tests To: Jan Beulich Cc: "binutils@sourceware.org" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00187.txt.bz2 On Tue, Feb 11, 2020 at 4:58 AM Jan Beulich wrote: > > On 11.02.2020 13:19, H.J. Lu wrote: > > On Tue, Feb 11, 2020 at 3:55 AM Jan Beulich wrote: > >> > >> On 11.02.2020 12:42, H.J. Lu wrote: > >>> On Tue, Feb 11, 2020 at 2:25 AM Jan Beulich wrote: > >>>> > >>>> Some encodings are about to gain a warning - move them from test cases > >>>> not expecting any diagnostics to the new, dedicated ones, to allow > >>>> better focus on the actual changes in the subsequent patch. > >>>> > >>>> The new tests added have some wrong expectations right now, which will > >>>> be corrected by the next patch. The test is being added here to make > >>>> more visible which cases actually were wrong (and hence get changed), > >>>> besides demonstrating that in the vast majority of cases the subsequent > >>>> change doesn't alter generated code. > >>>> > >>>> gas/ > >>>> 2020-02-XX Jan Beulich > >>>> > >>>> * testsuite/gas/i386/i386.s, testsuite/gas/i386/iamcu-1.s, > >>>> testsuite/gas/i386/ilp32/x86-64.s: Move ambiguous operand size > >>>> tests ... > >>>> * testsuite/gas/i386/noreg16.s, testsuite/gas/i386/noreg32.s, > >>>> testsuite/gas/i386/noreg64.s, testsuite/gas/i386/x86_64.s: ... > >>>> here. > >>>> * testsuite/gas/i386/i386.d, testsuite/gas/i386/i386-intel.d > >>>> testsuite/gas/i386/iamcu-1.d, testsuite/gas/i386/ilp32/x86-64.d, > >>>> testsuite/gas/i386/k1om.d, testsuite/gas/i386/l1om.d, > >>>> testsuite/gas/i386/noreg16.d, testsuite/gas/i386/noreg32.d, > >>>> testsuite/gas/i386/noreg64.d, testsuite/gas/i386/x86_64-intel.d, > >>>> testsuite/gas/i386/x86_64.d: Adjust expectations. > >>>> * testsuite/gas/i386/movx16.s, testsuite/gas/i386/movx16.l, > >>>> testsuite/gas/i386/movx32.s, testsuite/gas/i386/movx32.l, > >>>> testsuite/gas/i386/movx64.s, testsuite/gas/i386/movx64.l: New. > >>>> * testsuite/gas/i386/i386.exp: Run new tests. > >>> > >>> Please make a separate patch to address MOVSX/MOVZX. > >> > >> I don't understand what you mean here. This patch simply documents the > >> status quo, to make it (much) easier to see what the next patch > >> actually adjusts. It doesn't "address" anything. If, for the purpose > >> of committing, you'd like to see both patches folded - fine by me. But > >> only then, not any earlier. > >> > >>> MOVSX and MOVZX > >>> should take no suffixes. AT&T syntax is supported if there is no > >>> ambiguity. AT&T > >>> syntax also supports movsXY and movzXY. > >> > >> Please could you clarify what specifically you'd like to see changed, > >> at the very least by pointing out one case each where you think I'm > >> moving in the wrong direction (presumably in the next patch really)? > >> I'm afraid your response isn't such that I can derive from it what > >> exactly you want. > > > > We support > > > > movsx %ax, %ecx > > movzx %ax, %ecx > > movswl %ax, %ecx > > movzwl %ax, %ecx > > > > We disallow > > > > movsxw %ax, %ecx > > movzxw %ax, %ecx > > We don't (as this patch demonstrates, along with pre-existing tests, > unless you mean once again to have an inconsistency between insns > with all register operands and similar ones with e memory source), > and if you want it to be this way, then please do so yourself, but I will do it. > please also only on top of my changes, so I won't need to re-base Which changes of yours are you referring to? > _yet_ another time. > > Just to repeat my request from an earlier version: Please take the > time to check what this patch does (documenting _just_ current > behavior), and what the next patch changes behavior-wise. And > please comment on that following patch in case you think it makes > a change that it shouldn't make, i.e. in particular one which > isn't in line with other similar behavior. > > Jan -- H.J.