From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38390 invoked by alias); 23 Apr 2015 13:53:05 -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 38378 invoked by uid 89); 23 Apr 2015 13:53:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-oi0-f48.google.com Received: from mail-oi0-f48.google.com (HELO mail-oi0-f48.google.com) (209.85.218.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 23 Apr 2015 13:53:02 +0000 Received: by oift201 with SMTP id t201so14651456oif.3 for ; Thu, 23 Apr 2015 06:53:00 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.208.1 with SMTP id h1mr2384084oig.74.1429797180509; Thu, 23 Apr 2015 06:53:00 -0700 (PDT) Received: by 10.76.54.14 with HTTP; Thu, 23 Apr 2015 06:53:00 -0700 (PDT) In-Reply-To: <5539145B02000078000752F5@mail.emea.novell.com> References: <552FE0630200007800072CD0@mail.emea.novell.com> <55390A6A0200007800075263@mail.emea.novell.com> <5539145B02000078000752F5@mail.emea.novell.com> Date: Thu, 23 Apr 2015 13:53:00 -0000 Message-ID: Subject: Re: [PATCH] x86/Intel: accept mandated operand order for vcvt{,u}si2s{d,s} From: "H.J. Lu" To: Jan Beulich Cc: Kirill Yukhin , Binutils , "H. Peter Anvin" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00352.txt.bz2 On Thu, Apr 23, 2015 at 6:48 AM, Jan Beulich wrote: >>>> On 23.04.15 at 15:17, wrote: >> On Thu, Apr 23, 2015 at 6:06 AM, Jan Beulich wrote: >>>>>> On 23.04.15 at 14:39, wrote: >>>> On Thu, Apr 16, 2015 at 7:16 AM, Jan Beulich wrote: >>>>> As pointed out before, the documentation mandates the rounding mode to >>>>> follow the GPR, so gas should accept such input. As the brojen code got >>>>> released already we sadly will need to continue to also accept the >>>>> badly ordered operands. >>>>> >>>>> gas/testsuite/ >>>>> 2015-04-16 Jan Beulich >>>>> >>>>> * gas/i386/avx512f-intel.d: Adjust expectations on operand order. >>>>> * gas/i386/evex-lig256-intel.d: Likewise. >>>>> * gas/i386/evex-lig512-intel.d: Likewise. >>>>> * gas/i386/x86-64-avx512f-intel.d: Likewise. >>>>> * gas/i386/x86-64-evex-lig256-intel.d: Likewise. >>>>> * gas/i386/x86-64-evex-lig512-intel.d: Likewise. >>>>> >>>>> opcodes/ >>>>> 2015-04-16 Jan Beulich >>>>> >>>>> * i386-opc.tbl: New IntelSyntax entries for vcvt{,u}si2s{d,s}. >>>>> * i386-tbl.h: Regenerate. >>>>> >>>> >>>> I checked with our people. Intel Software Developer Manual only governs >>>> the output side of the binary form of instruction byte stream matches what >>>> HW expect. Each assembly tool product has its own implementation of >>>> transforming the input language/dialect into the output stream. In case of >>>> GNU assembler, operand order for AT&T and Intel syntax for AVX512 is >>>> the one used in AVX512 testcases. >>> >>> I don't mind AT&T being broken here (and elsewhere when it >>> comes to multiple source operands, as pointed out before), but >>> I do care about Intel syntax being in line with what the Intel >>> SDM says (and what I assume MASM is [going to] use). So >>> unless you're trying to tell me that the SDM is going to be >>> changed, or you have proof that MASM also deviates from what >>> the current documentation mandates ... >> >>>> It is not OK. >>> >>> ... I guess as the Intel syntax maintainer I could decide to ignore >>> this. >> >> MASM AVX512 compatibility isn't our goal. > > At the very least we shouldn't intentionally break such compatibility > (making porting more difficult). There is no MASM AVX512 that I know of and I don't know what syntax they will use if/when they implement it, -- H.J.