From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10265 invoked by alias); 5 May 2015 16:10:12 -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 10246 invoked by uid 89); 5 May 2015 16:10:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f171.google.com Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com) (209.85.214.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 05 May 2015 16:10:10 +0000 Received: by obblk2 with SMTP id lk2so105023114obb.0 for ; Tue, 05 May 2015 09:10:08 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.225.65 with SMTP id y62mr21972876oig.78.1430842208304; Tue, 05 May 2015 09:10:08 -0700 (PDT) Received: by 10.76.54.14 with HTTP; Tue, 5 May 2015 09:10:08 -0700 (PDT) In-Reply-To: <554906C70200007800076D28@mail.emea.novell.com> References: <552FE0630200007800072CD0@mail.emea.novell.com> <55390A6A0200007800075263@mail.emea.novell.com> <554906C70200007800076D28@mail.emea.novell.com> Date: Tue, 05 May 2015 16:10: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-05/txt/msg00029.txt.bz2 On Tue, May 5, 2015 at 9:07 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. Compatible with NASM is >> a good ideal. Peter, Kirill, let's work it out. >> >> Adding Peter for NASM and Kirill for GAS. > > Not having seen any response from them at all, I think applying > at least the assembler side (which leaves the current bogus > operand order available) should really not be controversial. As > to the disassembler side, I continue to think that Intel syntax > disassembly should preferably match the Intel manual, especially > when there is no other implementation to use as reference. > > Thoughts? > Since there is no MASM AVX512 compatibility to speak of, please don't apply those patches -- H.J.