This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] x86/Intel: accept mandated operand order for vcvt{,u}si2s{d,s}


On Thu, Apr 23, 2015 at 6:48 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 23.04.15 at 15:17, <hjl.tools@gmail.com> wrote:
>> On Thu, Apr 23, 2015 at 6:06 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 23.04.15 at 14:39, <hjl.tools@gmail.com> wrote:
>>>> On Thu, Apr 16, 2015 at 7:16 AM, Jan Beulich <JBeulich@suse.com> 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  <jbeulich@suse.com>
>>>>>
>>>>>         * 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  <jbeulich@suse.com>
>>>>>
>>>>>         * 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]