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

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

[Jan Beulich]

[-- Attachment #1: Type: text/plain, Size: 16480 bytes --]

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.

--- 2015-04-16/gas/testsuite/gas/i386/avx512f.s
+++ 2015-04-16/gas/testsuite/gas/i386/avx512f.s
@@ -9904,14 +9904,14 @@ _start:
 	vcvtsd2ss	xmm6{k7}, xmm5, QWORD PTR [edx-1032]	 # AVX512F
 
 
-	vcvtsi2ss	xmm6, xmm5, {rn-sae}, eax	 # AVX512F
-	vcvtsi2ss	xmm6, xmm5, {ru-sae}, eax	 # AVX512F
-	vcvtsi2ss	xmm6, xmm5, {rd-sae}, eax	 # AVX512F
-	vcvtsi2ss	xmm6, xmm5, {rz-sae}, eax	 # AVX512F
-	vcvtsi2ss	xmm6, xmm5, {rn-sae}, ebp	 # AVX512F
-	vcvtsi2ss	xmm6, xmm5, {ru-sae}, ebp	 # AVX512F
-	vcvtsi2ss	xmm6, xmm5, {rd-sae}, ebp	 # AVX512F
-	vcvtsi2ss	xmm6, xmm5, {rz-sae}, ebp	 # AVX512F
+	vcvtsi2ss	xmm6, xmm5, eax, {rn-sae}	 # AVX512F
+	vcvtsi2ss	xmm6, xmm5, eax, {ru-sae}	 # AVX512F
+	vcvtsi2ss	xmm6, xmm5, eax, {rd-sae}	 # AVX512F
+	vcvtsi2ss	xmm6, xmm5, eax, {rz-sae}	 # AVX512F
+	vcvtsi2ss	xmm6, xmm5, ebp, {rn-sae}	 # AVX512F
+	vcvtsi2ss	xmm6, xmm5, ebp, {ru-sae}	 # AVX512F
+	vcvtsi2ss	xmm6, xmm5, ebp, {rd-sae}	 # AVX512F
+	vcvtsi2ss	xmm6, xmm5, ebp, {rz-sae}	 # AVX512F
 
 	vcvtss2sd	xmm6{k7}, xmm5, xmm4	 # AVX512F
 	vcvtss2sd	xmm6{k7}{z}, xmm5, xmm4	 # AVX512F
@@ -13704,15 +13704,15 @@ _start:
 	vcvtusi2sd	xmm6, xmm5, DWORD PTR [edx-516]	 # AVX512F
 
 	vcvtusi2ss	xmm6, xmm5, eax	 # AVX512F
-	vcvtusi2ss	xmm6, xmm5, {rn-sae}, eax	 # AVX512F
-	vcvtusi2ss	xmm6, xmm5, {ru-sae}, eax	 # AVX512F
-	vcvtusi2ss	xmm6, xmm5, {rd-sae}, eax	 # AVX512F
-	vcvtusi2ss	xmm6, xmm5, {rz-sae}, eax	 # AVX512F
+	vcvtusi2ss	xmm6, xmm5, eax, {rn-sae}	 # AVX512F
+	vcvtusi2ss	xmm6, xmm5, eax, {ru-sae}	 # AVX512F
+	vcvtusi2ss	xmm6, xmm5, eax, {rd-sae}	 # AVX512F
+	vcvtusi2ss	xmm6, xmm5, eax, {rz-sae}	 # AVX512F
 	vcvtusi2ss	xmm6, xmm5, ebp	 # AVX512F
-	vcvtusi2ss	xmm6, xmm5, {rn-sae}, ebp	 # AVX512F
-	vcvtusi2ss	xmm6, xmm5, {ru-sae}, ebp	 # AVX512F
-	vcvtusi2ss	xmm6, xmm5, {rd-sae}, ebp	 # AVX512F
-	vcvtusi2ss	xmm6, xmm5, {rz-sae}, ebp	 # AVX512F
+	vcvtusi2ss	xmm6, xmm5, ebp, {rn-sae}	 # AVX512F
+	vcvtusi2ss	xmm6, xmm5, ebp, {ru-sae}	 # AVX512F
+	vcvtusi2ss	xmm6, xmm5, ebp, {rd-sae}	 # AVX512F
+	vcvtusi2ss	xmm6, xmm5, ebp, {rz-sae}	 # AVX512F
 	vcvtusi2ss	xmm6, xmm5, DWORD PTR [ecx]	 # AVX512F
 	vcvtusi2ss	xmm6, xmm5, DWORD PTR [esp+esi*8-123456]	 # AVX512F
 	vcvtusi2ss	xmm6, xmm5, DWORD PTR [edx+508]	 # AVX512F Disp8
--- 2015-04-16/gas/testsuite/gas/i386/x86-64-avx512f.s
+++ 2015-04-16/gas/testsuite/gas/i386/x86-64-avx512f.s
@@ -10339,15 +10339,15 @@ _start:
 	vcvtsi2sd	xmm30, xmm29, DWORD PTR [rdx-516]	 # AVX512F
 
 	vcvtsi2sd	xmm30, xmm29, rax	 # AVX512F
-	vcvtsi2sd	xmm30, xmm29, {rn-sae}, rax	 # AVX512F
-	vcvtsi2sd	xmm30, xmm29, {ru-sae}, rax	 # AVX512F
-	vcvtsi2sd	xmm30, xmm29, {rd-sae}, rax	 # AVX512F
-	vcvtsi2sd	xmm30, xmm29, {rz-sae}, rax	 # AVX512F
+	vcvtsi2sd	xmm30, xmm29, rax, {rn-sae}	 # AVX512F
+	vcvtsi2sd	xmm30, xmm29, rax, {ru-sae}	 # AVX512F
+	vcvtsi2sd	xmm30, xmm29, rax, {rd-sae}	 # AVX512F
+	vcvtsi2sd	xmm30, xmm29, rax, {rz-sae}	 # AVX512F
 	vcvtsi2sd	xmm30, xmm29, r8	 # AVX512F
-	vcvtsi2sd	xmm30, xmm29, {rn-sae}, r8	 # AVX512F
-	vcvtsi2sd	xmm30, xmm29, {ru-sae}, r8	 # AVX512F
-	vcvtsi2sd	xmm30, xmm29, {rd-sae}, r8	 # AVX512F
-	vcvtsi2sd	xmm30, xmm29, {rz-sae}, r8	 # AVX512F
+	vcvtsi2sd	xmm30, xmm29, r8, {rn-sae}	 # AVX512F
+	vcvtsi2sd	xmm30, xmm29, r8, {ru-sae}	 # AVX512F
+	vcvtsi2sd	xmm30, xmm29, r8, {rd-sae}	 # AVX512F
+	vcvtsi2sd	xmm30, xmm29, r8, {rz-sae}	 # AVX512F
 	vcvtsi2sd	xmm30, xmm29, QWORD PTR [rcx]	 # AVX512F
 	vcvtsi2sd	xmm30, xmm29, QWORD PTR [rax+r14*8+0x1234]	 # AVX512F
 	vcvtsi2sd	xmm30, xmm29, QWORD PTR [rdx+1016]	 # AVX512F Disp8
@@ -10356,20 +10356,20 @@ _start:
 	vcvtsi2sd	xmm30, xmm29, QWORD PTR [rdx-1032]	 # AVX512F
 
 	vcvtsi2ss	xmm30, xmm29, eax	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rn-sae}, eax	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {ru-sae}, eax	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rd-sae}, eax	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rz-sae}, eax	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, eax, {rn-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, eax, {ru-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, eax, {rd-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, eax, {rz-sae}	 # AVX512F
 	vcvtsi2ss	xmm30, xmm29, ebp	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rn-sae}, ebp	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {ru-sae}, ebp	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rd-sae}, ebp	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rz-sae}, ebp	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, ebp, {rn-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, ebp, {ru-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, ebp, {rd-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, ebp, {rz-sae}	 # AVX512F
 	vcvtsi2ss	xmm30, xmm29, r13d	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rn-sae}, r13d	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {ru-sae}, r13d	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rd-sae}, r13d	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rz-sae}, r13d	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, r13d, {rn-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, r13d, {ru-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, r13d, {rd-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, r13d, {rz-sae}	 # AVX512F
 	vcvtsi2ss	xmm30, xmm29, DWORD PTR [rcx]	 # AVX512F
 	vcvtsi2ss	xmm30, xmm29, DWORD PTR [rax+r14*8+0x1234]	 # AVX512F
 	vcvtsi2ss	xmm30, xmm29, DWORD PTR [rdx+508]	 # AVX512F Disp8
@@ -10378,15 +10378,15 @@ _start:
 	vcvtsi2ss	xmm30, xmm29, DWORD PTR [rdx-516]	 # AVX512F
 
 	vcvtsi2ss	xmm30, xmm29, rax	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rn-sae}, rax	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {ru-sae}, rax	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rd-sae}, rax	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rz-sae}, rax	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, rax, {rn-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, rax, {ru-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, rax, {rd-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, rax, {rz-sae}	 # AVX512F
 	vcvtsi2ss	xmm30, xmm29, r8	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rn-sae}, r8	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {ru-sae}, r8	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rd-sae}, r8	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rz-sae}, r8	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, r8, {rn-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, r8, {ru-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, r8, {rd-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, r8, {rz-sae}	 # AVX512F
 	vcvtsi2ss	xmm30, xmm29, QWORD PTR [rcx]	 # AVX512F
 	vcvtsi2ss	xmm30, xmm29, QWORD PTR [rax+r14*8+0x1234]	 # AVX512F
 	vcvtsi2ss	xmm30, xmm29, QWORD PTR [rdx+1016]	 # AVX512F Disp8
@@ -14409,15 +14409,15 @@ _start:
 	vcvtusi2sd	xmm30, xmm29, DWORD PTR [rdx-516]	 # AVX512F
 
 	vcvtusi2sd	xmm30, xmm29, rax	 # AVX512F
-	vcvtusi2sd	xmm30, xmm29, {rn-sae}, rax	 # AVX512F
-	vcvtusi2sd	xmm30, xmm29, {ru-sae}, rax	 # AVX512F
-	vcvtusi2sd	xmm30, xmm29, {rd-sae}, rax	 # AVX512F
-	vcvtusi2sd	xmm30, xmm29, {rz-sae}, rax	 # AVX512F
+	vcvtusi2sd	xmm30, xmm29, rax, {rn-sae}	 # AVX512F
+	vcvtusi2sd	xmm30, xmm29, rax, {ru-sae}	 # AVX512F
+	vcvtusi2sd	xmm30, xmm29, rax, {rd-sae}	 # AVX512F
+	vcvtusi2sd	xmm30, xmm29, rax, {rz-sae}	 # AVX512F
 	vcvtusi2sd	xmm30, xmm29, r8	 # AVX512F
-	vcvtusi2sd	xmm30, xmm29, {rn-sae}, r8	 # AVX512F
-	vcvtusi2sd	xmm30, xmm29, {ru-sae}, r8	 # AVX512F
-	vcvtusi2sd	xmm30, xmm29, {rd-sae}, r8	 # AVX512F
-	vcvtusi2sd	xmm30, xmm29, {rz-sae}, r8	 # AVX512F
+	vcvtusi2sd	xmm30, xmm29, r8, {rn-sae}	 # AVX512F
+	vcvtusi2sd	xmm30, xmm29, r8, {ru-sae}	 # AVX512F
+	vcvtusi2sd	xmm30, xmm29, r8, {rd-sae}	 # AVX512F
+	vcvtusi2sd	xmm30, xmm29, r8, {rz-sae}	 # AVX512F
 	vcvtusi2sd	xmm30, xmm29, QWORD PTR [rcx]	 # AVX512F
 	vcvtusi2sd	xmm30, xmm29, QWORD PTR [rax+r14*8+0x1234]	 # AVX512F
 	vcvtusi2sd	xmm30, xmm29, QWORD PTR [rdx+1016]	 # AVX512F Disp8
@@ -14426,20 +14426,20 @@ _start:
 	vcvtusi2sd	xmm30, xmm29, QWORD PTR [rdx-1032]	 # AVX512F
 
 	vcvtusi2ss	xmm30, xmm29, eax	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rn-sae}, eax	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {ru-sae}, eax	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rd-sae}, eax	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rz-sae}, eax	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, eax, {rn-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, eax, {ru-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, eax, {rd-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, eax, {rz-sae}	 # AVX512F
 	vcvtusi2ss	xmm30, xmm29, ebp	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rn-sae}, ebp	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {ru-sae}, ebp	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rd-sae}, ebp	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rz-sae}, ebp	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, ebp, {rn-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, ebp, {ru-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, ebp, {rd-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, ebp, {rz-sae}	 # AVX512F
 	vcvtusi2ss	xmm30, xmm29, r13d	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rn-sae}, r13d	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {ru-sae}, r13d	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rd-sae}, r13d	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rz-sae}, r13d	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, r13d, {rn-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, r13d, {ru-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, r13d, {rd-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, r13d, {rz-sae}	 # AVX512F
 	vcvtusi2ss	xmm30, xmm29, DWORD PTR [rcx]	 # AVX512F
 	vcvtusi2ss	xmm30, xmm29, DWORD PTR [rax+r14*8+0x1234]	 # AVX512F
 	vcvtusi2ss	xmm30, xmm29, DWORD PTR [rdx+508]	 # AVX512F Disp8
@@ -14448,15 +14448,15 @@ _start:
 	vcvtusi2ss	xmm30, xmm29, DWORD PTR [rdx-516]	 # AVX512F
 
 	vcvtusi2ss	xmm30, xmm29, rax	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rn-sae}, rax	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {ru-sae}, rax	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rd-sae}, rax	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rz-sae}, rax	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, rax, {rn-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, rax, {ru-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, rax, {rd-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, rax, {rz-sae}	 # AVX512F
 	vcvtusi2ss	xmm30, xmm29, r8	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rn-sae}, r8	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {ru-sae}, r8	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rd-sae}, r8	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rz-sae}, r8	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, r8, {rn-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, r8, {ru-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, r8, {rd-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, r8, {rz-sae}	 # AVX512F
 	vcvtusi2ss	xmm30, xmm29, QWORD PTR [rcx]	 # AVX512F
 	vcvtusi2ss	xmm30, xmm29, QWORD PTR [rax+r14*8+0x1234]	 # AVX512F
 	vcvtusi2ss	xmm30, xmm29, QWORD PTR [rdx+1016]	 # AVX512F Disp8
--- 2015-04-16/opcodes/i386-opc.tbl
+++ 2015-04-16/opcodes/i386-opc.tbl
@@ -3648,18 +3648,24 @@ vcvtsd2ss, 4, 0xF25A, None, 1, CpuAVX512
 vcvtsi2sd, 3, 0xF22A, None, 1, CpuAVX512F, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=1|Disp8MemShift=2|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Dword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|Vec_Disp8, RegXMM, RegXMM }
 vcvtsi2sd, 3, 0xF22A, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=2|VecESize=1|Disp8MemShift=3|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Reg64|Qword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|Vec_Disp8, RegXMM, RegXMM }
 vcvtsi2sd, 4, 0xF22A, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=2|VecESize=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|StaticRounding|SAE, { Reg64, Imm8, RegXMM, RegXMM }
+vcvtsi2sd, 4, 0xF22A, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=2|VecESize=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|StaticRounding|SAE|IntelSyntax, { Imm8, Reg64, RegXMM, RegXMM }
 vcvtusi2sd, 3, 0xF27B, None, 1, CpuAVX512F, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=1|Disp8MemShift=2|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Dword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|Vec_Disp8, RegXMM, RegXMM }
 vcvtusi2sd, 3, 0xF27B, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=2|VecESize=1|Disp8MemShift=3|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Reg64|Qword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|Vec_Disp8, RegXMM, RegXMM }
 vcvtusi2sd, 4, 0xF27B, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=2|VecESize=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|StaticRounding|SAE, { Reg64, Imm8, RegXMM, RegXMM }
+vcvtusi2sd, 4, 0xF27B, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=2|VecESize=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|StaticRounding|SAE|IntelSyntax, { Imm8, Reg64, RegXMM, RegXMM }
 
 vcvtsi2ss, 3, 0xF32A, None, 1, CpuAVX512F, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=1|Disp8MemShift=2|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Dword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|Vec_Disp8, RegXMM, RegXMM }
 vcvtsi2ss, 4, 0xF32A, None, 1, CpuAVX512F, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=1|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf|StaticRounding|SAE, { Reg32, Imm8, RegXMM, RegXMM }
+vcvtsi2ss, 4, 0xF32A, None, 1, CpuAVX512F, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=1|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf|StaticRounding|SAE|IntelSyntax, { Imm8, Reg32, RegXMM, RegXMM }
 vcvtsi2ss, 3, 0xF32A, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=2|VecESize=1|Disp8MemShift=3|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Reg64|Qword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|Vec_Disp8, RegXMM, RegXMM }
 vcvtsi2ss, 4, 0xF32A, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=2|VecESize=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|StaticRounding|SAE, { Reg64, Imm8, RegXMM, RegXMM }
+vcvtsi2ss, 4, 0xF32A, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=2|VecESize=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|StaticRounding|SAE|IntelSyntax, { Imm8, Reg64, RegXMM, RegXMM }
 vcvtusi2ss, 3, 0xF37B, None, 1, CpuAVX512F, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=1|Disp8MemShift=2|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Dword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|Vec_Disp8, RegXMM, RegXMM }
 vcvtusi2ss, 4, 0xF37B, None, 1, CpuAVX512F, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=1|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf|StaticRounding|SAE, { Reg32, Imm8, RegXMM, RegXMM }
+vcvtusi2ss, 4, 0xF37B, None, 1, CpuAVX512F, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=1|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf|StaticRounding|SAE|IntelSyntax, { Imm8, Reg32, RegXMM, RegXMM }
 vcvtusi2ss, 3, 0xF37B, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=2|VecESize=1|Disp8MemShift=3|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Reg64|Qword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|Vec_Disp8, RegXMM, RegXMM }
 vcvtusi2ss, 4, 0xF37B, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=2|VecESize=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|StaticRounding|SAE, { Reg64, Imm8, RegXMM, RegXMM }
+vcvtusi2ss, 4, 0xF37B, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=2|VecESize=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|StaticRounding|SAE|IntelSyntax, { Imm8, Reg64, RegXMM, RegXMM }
 
 vcvtss2sd, 3, 0xF35A, None, 1, CpuAVX512F, Modrm|EVex=4|Masking=3|VexOpcode=0|VexVVVV=1|VexW=1|Disp8MemShift=2|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { RegXMM|Dword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|Vec_Disp8, RegXMM, RegXMM }
 vcvtss2sd, 4, 0xF35A, None, 1, CpuAVX512F, Modrm|EVex=4|Masking=3|VexOpcode=0|VexVVVV=1|VexW=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|SAE, { Imm8, RegXMM, RegXMM, RegXMM }



[-- Attachment #2: binutils-master-x86-AVX512F-scalar-convert-asm.patch --]
[-- Type: text/plain, Size: 26866 bytes --]

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

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.

--- 2015-04-16/gas/testsuite/gas/i386/avx512f.s
+++ 2015-04-16/gas/testsuite/gas/i386/avx512f.s
@@ -9904,14 +9904,14 @@ _start:
 	vcvtsd2ss	xmm6{k7}, xmm5, QWORD PTR [edx-1032]	 # AVX512F
 
 
-	vcvtsi2ss	xmm6, xmm5, {rn-sae}, eax	 # AVX512F
-	vcvtsi2ss	xmm6, xmm5, {ru-sae}, eax	 # AVX512F
-	vcvtsi2ss	xmm6, xmm5, {rd-sae}, eax	 # AVX512F
-	vcvtsi2ss	xmm6, xmm5, {rz-sae}, eax	 # AVX512F
-	vcvtsi2ss	xmm6, xmm5, {rn-sae}, ebp	 # AVX512F
-	vcvtsi2ss	xmm6, xmm5, {ru-sae}, ebp	 # AVX512F
-	vcvtsi2ss	xmm6, xmm5, {rd-sae}, ebp	 # AVX512F
-	vcvtsi2ss	xmm6, xmm5, {rz-sae}, ebp	 # AVX512F
+	vcvtsi2ss	xmm6, xmm5, eax, {rn-sae}	 # AVX512F
+	vcvtsi2ss	xmm6, xmm5, eax, {ru-sae}	 # AVX512F
+	vcvtsi2ss	xmm6, xmm5, eax, {rd-sae}	 # AVX512F
+	vcvtsi2ss	xmm6, xmm5, eax, {rz-sae}	 # AVX512F
+	vcvtsi2ss	xmm6, xmm5, ebp, {rn-sae}	 # AVX512F
+	vcvtsi2ss	xmm6, xmm5, ebp, {ru-sae}	 # AVX512F
+	vcvtsi2ss	xmm6, xmm5, ebp, {rd-sae}	 # AVX512F
+	vcvtsi2ss	xmm6, xmm5, ebp, {rz-sae}	 # AVX512F
 
 	vcvtss2sd	xmm6{k7}, xmm5, xmm4	 # AVX512F
 	vcvtss2sd	xmm6{k7}{z}, xmm5, xmm4	 # AVX512F
@@ -13704,15 +13704,15 @@ _start:
 	vcvtusi2sd	xmm6, xmm5, DWORD PTR [edx-516]	 # AVX512F
 
 	vcvtusi2ss	xmm6, xmm5, eax	 # AVX512F
-	vcvtusi2ss	xmm6, xmm5, {rn-sae}, eax	 # AVX512F
-	vcvtusi2ss	xmm6, xmm5, {ru-sae}, eax	 # AVX512F
-	vcvtusi2ss	xmm6, xmm5, {rd-sae}, eax	 # AVX512F
-	vcvtusi2ss	xmm6, xmm5, {rz-sae}, eax	 # AVX512F
+	vcvtusi2ss	xmm6, xmm5, eax, {rn-sae}	 # AVX512F
+	vcvtusi2ss	xmm6, xmm5, eax, {ru-sae}	 # AVX512F
+	vcvtusi2ss	xmm6, xmm5, eax, {rd-sae}	 # AVX512F
+	vcvtusi2ss	xmm6, xmm5, eax, {rz-sae}	 # AVX512F
 	vcvtusi2ss	xmm6, xmm5, ebp	 # AVX512F
-	vcvtusi2ss	xmm6, xmm5, {rn-sae}, ebp	 # AVX512F
-	vcvtusi2ss	xmm6, xmm5, {ru-sae}, ebp	 # AVX512F
-	vcvtusi2ss	xmm6, xmm5, {rd-sae}, ebp	 # AVX512F
-	vcvtusi2ss	xmm6, xmm5, {rz-sae}, ebp	 # AVX512F
+	vcvtusi2ss	xmm6, xmm5, ebp, {rn-sae}	 # AVX512F
+	vcvtusi2ss	xmm6, xmm5, ebp, {ru-sae}	 # AVX512F
+	vcvtusi2ss	xmm6, xmm5, ebp, {rd-sae}	 # AVX512F
+	vcvtusi2ss	xmm6, xmm5, ebp, {rz-sae}	 # AVX512F
 	vcvtusi2ss	xmm6, xmm5, DWORD PTR [ecx]	 # AVX512F
 	vcvtusi2ss	xmm6, xmm5, DWORD PTR [esp+esi*8-123456]	 # AVX512F
 	vcvtusi2ss	xmm6, xmm5, DWORD PTR [edx+508]	 # AVX512F Disp8
--- 2015-04-16/gas/testsuite/gas/i386/x86-64-avx512f.s
+++ 2015-04-16/gas/testsuite/gas/i386/x86-64-avx512f.s
@@ -10339,15 +10339,15 @@ _start:
 	vcvtsi2sd	xmm30, xmm29, DWORD PTR [rdx-516]	 # AVX512F
 
 	vcvtsi2sd	xmm30, xmm29, rax	 # AVX512F
-	vcvtsi2sd	xmm30, xmm29, {rn-sae}, rax	 # AVX512F
-	vcvtsi2sd	xmm30, xmm29, {ru-sae}, rax	 # AVX512F
-	vcvtsi2sd	xmm30, xmm29, {rd-sae}, rax	 # AVX512F
-	vcvtsi2sd	xmm30, xmm29, {rz-sae}, rax	 # AVX512F
+	vcvtsi2sd	xmm30, xmm29, rax, {rn-sae}	 # AVX512F
+	vcvtsi2sd	xmm30, xmm29, rax, {ru-sae}	 # AVX512F
+	vcvtsi2sd	xmm30, xmm29, rax, {rd-sae}	 # AVX512F
+	vcvtsi2sd	xmm30, xmm29, rax, {rz-sae}	 # AVX512F
 	vcvtsi2sd	xmm30, xmm29, r8	 # AVX512F
-	vcvtsi2sd	xmm30, xmm29, {rn-sae}, r8	 # AVX512F
-	vcvtsi2sd	xmm30, xmm29, {ru-sae}, r8	 # AVX512F
-	vcvtsi2sd	xmm30, xmm29, {rd-sae}, r8	 # AVX512F
-	vcvtsi2sd	xmm30, xmm29, {rz-sae}, r8	 # AVX512F
+	vcvtsi2sd	xmm30, xmm29, r8, {rn-sae}	 # AVX512F
+	vcvtsi2sd	xmm30, xmm29, r8, {ru-sae}	 # AVX512F
+	vcvtsi2sd	xmm30, xmm29, r8, {rd-sae}	 # AVX512F
+	vcvtsi2sd	xmm30, xmm29, r8, {rz-sae}	 # AVX512F
 	vcvtsi2sd	xmm30, xmm29, QWORD PTR [rcx]	 # AVX512F
 	vcvtsi2sd	xmm30, xmm29, QWORD PTR [rax+r14*8+0x1234]	 # AVX512F
 	vcvtsi2sd	xmm30, xmm29, QWORD PTR [rdx+1016]	 # AVX512F Disp8
@@ -10356,20 +10356,20 @@ _start:
 	vcvtsi2sd	xmm30, xmm29, QWORD PTR [rdx-1032]	 # AVX512F
 
 	vcvtsi2ss	xmm30, xmm29, eax	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rn-sae}, eax	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {ru-sae}, eax	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rd-sae}, eax	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rz-sae}, eax	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, eax, {rn-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, eax, {ru-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, eax, {rd-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, eax, {rz-sae}	 # AVX512F
 	vcvtsi2ss	xmm30, xmm29, ebp	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rn-sae}, ebp	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {ru-sae}, ebp	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rd-sae}, ebp	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rz-sae}, ebp	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, ebp, {rn-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, ebp, {ru-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, ebp, {rd-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, ebp, {rz-sae}	 # AVX512F
 	vcvtsi2ss	xmm30, xmm29, r13d	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rn-sae}, r13d	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {ru-sae}, r13d	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rd-sae}, r13d	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rz-sae}, r13d	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, r13d, {rn-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, r13d, {ru-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, r13d, {rd-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, r13d, {rz-sae}	 # AVX512F
 	vcvtsi2ss	xmm30, xmm29, DWORD PTR [rcx]	 # AVX512F
 	vcvtsi2ss	xmm30, xmm29, DWORD PTR [rax+r14*8+0x1234]	 # AVX512F
 	vcvtsi2ss	xmm30, xmm29, DWORD PTR [rdx+508]	 # AVX512F Disp8
@@ -10378,15 +10378,15 @@ _start:
 	vcvtsi2ss	xmm30, xmm29, DWORD PTR [rdx-516]	 # AVX512F
 
 	vcvtsi2ss	xmm30, xmm29, rax	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rn-sae}, rax	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {ru-sae}, rax	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rd-sae}, rax	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rz-sae}, rax	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, rax, {rn-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, rax, {ru-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, rax, {rd-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, rax, {rz-sae}	 # AVX512F
 	vcvtsi2ss	xmm30, xmm29, r8	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rn-sae}, r8	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {ru-sae}, r8	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rd-sae}, r8	 # AVX512F
-	vcvtsi2ss	xmm30, xmm29, {rz-sae}, r8	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, r8, {rn-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, r8, {ru-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, r8, {rd-sae}	 # AVX512F
+	vcvtsi2ss	xmm30, xmm29, r8, {rz-sae}	 # AVX512F
 	vcvtsi2ss	xmm30, xmm29, QWORD PTR [rcx]	 # AVX512F
 	vcvtsi2ss	xmm30, xmm29, QWORD PTR [rax+r14*8+0x1234]	 # AVX512F
 	vcvtsi2ss	xmm30, xmm29, QWORD PTR [rdx+1016]	 # AVX512F Disp8
@@ -14409,15 +14409,15 @@ _start:
 	vcvtusi2sd	xmm30, xmm29, DWORD PTR [rdx-516]	 # AVX512F
 
 	vcvtusi2sd	xmm30, xmm29, rax	 # AVX512F
-	vcvtusi2sd	xmm30, xmm29, {rn-sae}, rax	 # AVX512F
-	vcvtusi2sd	xmm30, xmm29, {ru-sae}, rax	 # AVX512F
-	vcvtusi2sd	xmm30, xmm29, {rd-sae}, rax	 # AVX512F
-	vcvtusi2sd	xmm30, xmm29, {rz-sae}, rax	 # AVX512F
+	vcvtusi2sd	xmm30, xmm29, rax, {rn-sae}	 # AVX512F
+	vcvtusi2sd	xmm30, xmm29, rax, {ru-sae}	 # AVX512F
+	vcvtusi2sd	xmm30, xmm29, rax, {rd-sae}	 # AVX512F
+	vcvtusi2sd	xmm30, xmm29, rax, {rz-sae}	 # AVX512F
 	vcvtusi2sd	xmm30, xmm29, r8	 # AVX512F
-	vcvtusi2sd	xmm30, xmm29, {rn-sae}, r8	 # AVX512F
-	vcvtusi2sd	xmm30, xmm29, {ru-sae}, r8	 # AVX512F
-	vcvtusi2sd	xmm30, xmm29, {rd-sae}, r8	 # AVX512F
-	vcvtusi2sd	xmm30, xmm29, {rz-sae}, r8	 # AVX512F
+	vcvtusi2sd	xmm30, xmm29, r8, {rn-sae}	 # AVX512F
+	vcvtusi2sd	xmm30, xmm29, r8, {ru-sae}	 # AVX512F
+	vcvtusi2sd	xmm30, xmm29, r8, {rd-sae}	 # AVX512F
+	vcvtusi2sd	xmm30, xmm29, r8, {rz-sae}	 # AVX512F
 	vcvtusi2sd	xmm30, xmm29, QWORD PTR [rcx]	 # AVX512F
 	vcvtusi2sd	xmm30, xmm29, QWORD PTR [rax+r14*8+0x1234]	 # AVX512F
 	vcvtusi2sd	xmm30, xmm29, QWORD PTR [rdx+1016]	 # AVX512F Disp8
@@ -14426,20 +14426,20 @@ _start:
 	vcvtusi2sd	xmm30, xmm29, QWORD PTR [rdx-1032]	 # AVX512F
 
 	vcvtusi2ss	xmm30, xmm29, eax	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rn-sae}, eax	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {ru-sae}, eax	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rd-sae}, eax	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rz-sae}, eax	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, eax, {rn-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, eax, {ru-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, eax, {rd-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, eax, {rz-sae}	 # AVX512F
 	vcvtusi2ss	xmm30, xmm29, ebp	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rn-sae}, ebp	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {ru-sae}, ebp	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rd-sae}, ebp	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rz-sae}, ebp	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, ebp, {rn-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, ebp, {ru-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, ebp, {rd-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, ebp, {rz-sae}	 # AVX512F
 	vcvtusi2ss	xmm30, xmm29, r13d	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rn-sae}, r13d	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {ru-sae}, r13d	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rd-sae}, r13d	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rz-sae}, r13d	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, r13d, {rn-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, r13d, {ru-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, r13d, {rd-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, r13d, {rz-sae}	 # AVX512F
 	vcvtusi2ss	xmm30, xmm29, DWORD PTR [rcx]	 # AVX512F
 	vcvtusi2ss	xmm30, xmm29, DWORD PTR [rax+r14*8+0x1234]	 # AVX512F
 	vcvtusi2ss	xmm30, xmm29, DWORD PTR [rdx+508]	 # AVX512F Disp8
@@ -14448,15 +14448,15 @@ _start:
 	vcvtusi2ss	xmm30, xmm29, DWORD PTR [rdx-516]	 # AVX512F
 
 	vcvtusi2ss	xmm30, xmm29, rax	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rn-sae}, rax	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {ru-sae}, rax	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rd-sae}, rax	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rz-sae}, rax	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, rax, {rn-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, rax, {ru-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, rax, {rd-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, rax, {rz-sae}	 # AVX512F
 	vcvtusi2ss	xmm30, xmm29, r8	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rn-sae}, r8	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {ru-sae}, r8	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rd-sae}, r8	 # AVX512F
-	vcvtusi2ss	xmm30, xmm29, {rz-sae}, r8	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, r8, {rn-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, r8, {ru-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, r8, {rd-sae}	 # AVX512F
+	vcvtusi2ss	xmm30, xmm29, r8, {rz-sae}	 # AVX512F
 	vcvtusi2ss	xmm30, xmm29, QWORD PTR [rcx]	 # AVX512F
 	vcvtusi2ss	xmm30, xmm29, QWORD PTR [rax+r14*8+0x1234]	 # AVX512F
 	vcvtusi2ss	xmm30, xmm29, QWORD PTR [rdx+1016]	 # AVX512F Disp8
--- 2015-04-16/opcodes/i386-opc.tbl
+++ 2015-04-16/opcodes/i386-opc.tbl
@@ -3648,18 +3648,24 @@ vcvtsd2ss, 4, 0xF25A, None, 1, CpuAVX512
 vcvtsi2sd, 3, 0xF22A, None, 1, CpuAVX512F, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=1|Disp8MemShift=2|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Dword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|Vec_Disp8, RegXMM, RegXMM }
 vcvtsi2sd, 3, 0xF22A, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=2|VecESize=1|Disp8MemShift=3|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Reg64|Qword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|Vec_Disp8, RegXMM, RegXMM }
 vcvtsi2sd, 4, 0xF22A, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=2|VecESize=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|StaticRounding|SAE, { Reg64, Imm8, RegXMM, RegXMM }
+vcvtsi2sd, 4, 0xF22A, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=2|VecESize=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|StaticRounding|SAE|IntelSyntax, { Imm8, Reg64, RegXMM, RegXMM }
 vcvtusi2sd, 3, 0xF27B, None, 1, CpuAVX512F, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=1|Disp8MemShift=2|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Dword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|Vec_Disp8, RegXMM, RegXMM }
 vcvtusi2sd, 3, 0xF27B, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=2|VecESize=1|Disp8MemShift=3|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Reg64|Qword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|Vec_Disp8, RegXMM, RegXMM }
 vcvtusi2sd, 4, 0xF27B, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=2|VecESize=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|StaticRounding|SAE, { Reg64, Imm8, RegXMM, RegXMM }
+vcvtusi2sd, 4, 0xF27B, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=2|VecESize=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|StaticRounding|SAE|IntelSyntax, { Imm8, Reg64, RegXMM, RegXMM }
 
 vcvtsi2ss, 3, 0xF32A, None, 1, CpuAVX512F, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=1|Disp8MemShift=2|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Dword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|Vec_Disp8, RegXMM, RegXMM }
 vcvtsi2ss, 4, 0xF32A, None, 1, CpuAVX512F, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=1|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf|StaticRounding|SAE, { Reg32, Imm8, RegXMM, RegXMM }
+vcvtsi2ss, 4, 0xF32A, None, 1, CpuAVX512F, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=1|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf|StaticRounding|SAE|IntelSyntax, { Imm8, Reg32, RegXMM, RegXMM }
 vcvtsi2ss, 3, 0xF32A, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=2|VecESize=1|Disp8MemShift=3|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Reg64|Qword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|Vec_Disp8, RegXMM, RegXMM }
 vcvtsi2ss, 4, 0xF32A, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=2|VecESize=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|StaticRounding|SAE, { Reg64, Imm8, RegXMM, RegXMM }
+vcvtsi2ss, 4, 0xF32A, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=2|VecESize=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|StaticRounding|SAE|IntelSyntax, { Imm8, Reg64, RegXMM, RegXMM }
 vcvtusi2ss, 3, 0xF37B, None, 1, CpuAVX512F, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=1|Disp8MemShift=2|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Dword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|Vec_Disp8, RegXMM, RegXMM }
 vcvtusi2ss, 4, 0xF37B, None, 1, CpuAVX512F, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=1|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf|StaticRounding|SAE, { Reg32, Imm8, RegXMM, RegXMM }
+vcvtusi2ss, 4, 0xF37B, None, 1, CpuAVX512F, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=1|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf|StaticRounding|SAE|IntelSyntax, { Imm8, Reg32, RegXMM, RegXMM }
 vcvtusi2ss, 3, 0xF37B, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=2|VecESize=1|Disp8MemShift=3|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf, { Reg64|Qword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|Vec_Disp8, RegXMM, RegXMM }
 vcvtusi2ss, 4, 0xF37B, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=2|VecESize=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|StaticRounding|SAE, { Reg64, Imm8, RegXMM, RegXMM }
+vcvtusi2ss, 4, 0xF37B, None, 1, CpuAVX512F|Cpu64, Modrm|EVex=4|VexOpcode=0|VexVVVV=1|VexW=2|VecESize=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|StaticRounding|SAE|IntelSyntax, { Imm8, Reg64, RegXMM, RegXMM }
 
 vcvtss2sd, 3, 0xF35A, None, 1, CpuAVX512F, Modrm|EVex=4|Masking=3|VexOpcode=0|VexVVVV=1|VexW=1|Disp8MemShift=2|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { RegXMM|Dword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|Vec_Disp8, RegXMM, RegXMM }
 vcvtss2sd, 4, 0xF35A, None, 1, CpuAVX512F, Modrm|EVex=4|Masking=3|VexOpcode=0|VexVVVV=1|VexW=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|SAE, { Imm8, RegXMM, RegXMM, RegXMM }
--- 2015-04-16/opcodes/i386-tbl.h
+++ 2015-04-16/opcodes/i386-tbl.h
@@ -36698,6 +36698,28 @@ const insn_template i386_optab[] =
       { { 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } } } },
+  { "vcvtsi2sd", 4, 0xF22A, None, 1,
+    { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 1, 0, 0 } },
+    { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 1,
+      1, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+      0, 0, 1, 2, 0, 0, 0, 0, 0, 0, 4, 0, 1, 0, 1, 1, 0, 0, 0, 0,
+      0, 1 },
+    { { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
+      { { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
+      { { 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
+      { { 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } } } },
   { "vcvtsi2ss", 3, 0xf32a, None, 1,
     { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
         0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
@@ -36777,6 +36799,28 @@ const insn_template i386_optab[] =
       { { 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } } } },
+  { "vcvtsi2ss", 4, 0xF32A, None, 1,
+    { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 0, 0, 0 } },
+    { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 1,
+      0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+      0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 1, 1, 0, 0, 0, 0,
+      0, 1 },
+    { { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
+      { { 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
+      { { 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
+      { { 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } } } },
   { "vcvtsi2ss", 3, 0xF32A, None, 1,
     { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
         0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0,
@@ -36818,6 +36862,28 @@ const insn_template i386_optab[] =
       { { 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } } } },
+  { "vcvtsi2ss", 4, 0xF32A, None, 1,
+    { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 1, 0, 0 } },
+    { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 1,
+      1, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+      0, 0, 1, 2, 0, 0, 0, 0, 0, 0, 4, 0, 1, 0, 1, 1, 0, 0, 0, 0,
+      0, 1 },
+    { { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
+      { { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
+      { { 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
+      { { 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } } } },
   { "vcvtss2sd", 3, 0xf35a, None, 1,
     { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
         0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
@@ -76662,6 +76728,28 @@ const insn_template i386_optab[] =
       { { 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } } } },
+  { "vcvtusi2sd", 4, 0xF27B, None, 1,
+    { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 1, 0, 0 } },
+    { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 1,
+      1, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+      0, 0, 1, 2, 0, 0, 0, 0, 0, 0, 4, 0, 1, 0, 1, 1, 0, 0, 0, 0,
+      0, 1 },
+    { { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
+      { { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
+      { { 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
+      { { 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } } } },
   { "vcvtusi2ss", 3, 0xF37B, None, 1,
     { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
         0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0,
@@ -76703,6 +76791,28 @@ const insn_template i386_optab[] =
       { { 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } } } },
+  { "vcvtusi2ss", 4, 0xF37B, None, 1,
+    { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 0, 0, 0 } },
+    { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 1,
+      0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+      0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 1, 1, 0, 0, 0, 0,
+      0, 1 },
+    { { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
+      { { 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
+      { { 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
+      { { 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } } } },
   { "vcvtusi2ss", 3, 0xF37B, None, 1,
     { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
         0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0,
@@ -76744,6 +76854,28 @@ const insn_template i386_optab[] =
       { { 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } } } },
+  { "vcvtusi2ss", 4, 0xF37B, None, 1,
+    { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+        0, 1, 0, 0 } },
+    { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 1,
+      1, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+      0, 0, 1, 2, 0, 0, 0, 0, 0, 0, 4, 0, 1, 0, 1, 1, 0, 0, 0, 0,
+      0, 1 },
+    { { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
+      { { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
+      { { 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
+      { { 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+	  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } } } },
   { "vcvtss2usi", 2, 0xF379, None, 1,
     { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
         0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0,

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

[H.J. Lu]

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.

It is not OK.


-- 
H.J.

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

[Jan Beulich]

>>> 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.

Jan

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

[H.J. Lu]

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.  Compatible with NASM is
a good ideal.  Peter, Kirill, let's work it out.

Adding Peter for NASM and Kirill for GAS.

Thanks.

-- 
H.J.

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

[Jan Beulich]

>>> 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).

Jan

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

[H.J. Lu]

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.

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

[Jan Beulich]

>>> 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.  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?

Thanks, Jan

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

[H.J. Lu]

On Tue, May 5, 2015 at 9:07 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.  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.

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

[Jan Beulich]

>>> On 05.05.15 at 18:10, <hjl.tools@gmail.com> wrote:
> On Tue, May 5, 2015 at 9:07 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:
>>>>> 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

Please don't just repeat yourself, but give a reason I can understand
to override the intention to conform with the Intel manual. I'm
certainly hesitant to commit changes that can't be agreed upon, but
as said before I don't feel tied to your disapproval of the changes.

Jan

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

[Jan Beulich]

>>> On 06.05.15 at 09:44, <JBeulich@suse.com> wrote:
> Please don't just repeat yourself, but give a reason I can understand
> to override the intention to conform with the Intel manual. I'm
> certainly hesitant to commit changes that can't be agreed upon, but
> as said before I don't feel tied to your disapproval of the changes.

I guess I'll take two weeks of silence as silent withdrawal of the
objection to the patches then.

Jan

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

[H.J. Lu]

On Wed, May 20, 2015 at 11:30 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 06.05.15 at 09:44, <JBeulich@suse.com> wrote:
>> Please don't just repeat yourself, but give a reason I can understand
>> to override the intention to conform with the Intel manual. I'm
>> certainly hesitant to commit changes that can't be agreed upon, but
>> as said before I don't feel tied to your disapproval of the changes.
>
> I guess I'll take two weeks of silence as silent withdrawal of the
> objection to the patches then.

Please don't change it. As I said before, we have discussed it at Intel
and we don't think the change is appropriate.


-- 
H.J.

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

[Jan Beulich]

>>> On 21.05.15 at 12:42, <hjl.tools@gmail.com> wrote:
> On Wed, May 20, 2015 at 11:30 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 06.05.15 at 09:44, <JBeulich@suse.com> wrote:
>>> Please don't just repeat yourself, but give a reason I can understand
>>> to override the intention to conform with the Intel manual. I'm
>>> certainly hesitant to commit changes that can't be agreed upon, but
>>> as said before I don't feel tied to your disapproval of the changes.
>>
>> I guess I'll take two weeks of silence as silent withdrawal of the
>> objection to the patches then.
> 
> Please don't change it. As I said before, we have discussed it at Intel
> and we don't think the change is appropriate.

So are you planning to change the SDM? Else I don't see what new
aspect you are trying to tell me. I'm hesitant to commit the changes
without your consent, but getting back silence or all the same
vague arguments I'm afraid all I can do is give you a little more
time (say a week; if you need more, please give a clear time line) to
come forward with something substantial.

(Also please recall me having stated before that the AT&T operand
ordering has got completely screwed up over its apparent original
intentions with all the more-than-two operand instructions that got
added over the last so many years. This brokenness should _not_
impact Intel syntax mode.)

Jan

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

[H.J. Lu]

On Thu, May 21, 2015 at 4:36 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 21.05.15 at 12:42, <hjl.tools@gmail.com> wrote:
>> On Wed, May 20, 2015 at 11:30 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 06.05.15 at 09:44, <JBeulich@suse.com> wrote:
>>>> Please don't just repeat yourself, but give a reason I can understand
>>>> to override the intention to conform with the Intel manual. I'm
>>>> certainly hesitant to commit changes that can't be agreed upon, but
>>>> as said before I don't feel tied to your disapproval of the changes.
>>>
>>> I guess I'll take two weeks of silence as silent withdrawal of the
>>> objection to the patches then.
>>
>> Please don't change it. As I said before, we have discussed it at Intel
>> and we don't think the change is appropriate.
>
> So are you planning to change the SDM? Else I don't see what new
> aspect you are trying to tell me. I'm hesitant to commit the changes
> without your consent, but getting back silence or all the same
> vague arguments I'm afraid all I can do is give you a little more
> time (say a week; if you need more, please give a clear time line) to
> come forward with something substantial.

I checked with our SDM people and was told that

---
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.
---

Intel syntax supported by GNU assembler is what is implemented
in GNU assembler.  Given that there is nothing we can be compatible
with, we don't want to change it.

> (Also please recall me having stated before that the AT&T operand
> ordering has got completely screwed up over its apparent original
> intentions with all the more-than-two operand instructions that got
> added over the last so many years. This brokenness should _not_
> impact Intel syntax mode.)
>

I agreed with you on this.  But it was before my time and I can't
change it.


-- 
H.J.

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

[Jan Beulich]

>>> On 21.05.15 at 14:07, <hjl.tools@gmail.com> wrote:
> I checked with our SDM people and was told that
> 
> ---
> 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.
> ---

Of course. But I don't think you're going to deny that what it (or
really its ancient predecessors) specified has been taken by
assembler implementations as reference.

> Intel syntax supported by GNU assembler is what is implemented
> in GNU assembler.  Given that there is nothing we can be compatible
> with, we don't want to change it.

I clearly disagree to this last statement, and I think you saying so
contradicts you having pulled in people maintaining other assemblers
apparently in the hope that they would support your position (which
they didn't, at least not publicly, i.e. not visible to me).

Furthermore you once again ignore the fact that the assembler
after my proposed changes isn't going to reject the previously
supported format, it merely _also_ supports the SDM specified
variant. Hence I don't see the change breaking anything, and I
continue having a hard time understanding your position in the
first place.

Jan

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

[H.J. Lu]

On Thu, May 21, 2015 at 8:02 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 21.05.15 at 14:07, <hjl.tools@gmail.com> wrote:
>> I checked with our SDM people and was told that
>>
>> ---
>> 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.
>> ---
>
> Of course. But I don't think you're going to deny that what it (or
> really its ancient predecessors) specified has been taken by
> assembler implementations as reference.

Intel SDM is NOT an assembler reference manual.  Please stop
making it into one.

>> Intel syntax supported by GNU assembler is what is implemented
>> in GNU assembler.  Given that there is nothing we can be compatible
>> with, we don't want to change it.
>
> I clearly disagree to this last statement, and I think you saying so
> contradicts you having pulled in people maintaining other assemblers
> apparently in the hope that they would support your position (which
> they didn't, at least not publicly, i.e. not visible to me).

It simply means that they don't care.

> Furthermore you once again ignore the fact that the assembler
> after my proposed changes isn't going to reject the previously
> supported format, it merely _also_ supports the SDM specified
> variant. Hence I don't see the change breaking anything, and I
> continue having a hard time understanding your position in the
> first place.
>

We don't want to introduce new syntax which isn't used by
ANYONE.

-- 
H.J.

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

[Jan Beulich]

>>> On 21.05.15 at 17:11, <hjl.tools@gmail.com> wrote:
> On Thu, May 21, 2015 at 8:02 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 21.05.15 at 14:07, <hjl.tools@gmail.com> wrote:
>>> I checked with our SDM people and was told that
>>>
>>> ---
>>> 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.
>>> ---
>>
>> Of course. But I don't think you're going to deny that what it (or
>> really its ancient predecessors) specified has been taken by
>> assembler implementations as reference.
> 
> Intel SDM is NOT an assembler reference manual.  Please stop
> making it into one.

It's not, I agree. But in the absence of any other one, it is (and
imo ought to be) used as a reference anyway.

Jan

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

[Kirill Yukhin]

Folks,

On 05 May 17:07, Jan Beulich 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.  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?
Wanted to mention couple of points:
  1. I agree w/ HJ: SDM is not a source of syntax
  2. We have two product already released: ICC (2 version at the moment) and GCC
  (4.9 and 5) which use existing syntax for emitting those insns

Said that, I don't see any reason to introduce (not replace) alternative operand order.

--
Thanks, K

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

[Jan Beulich]

>>> On 25.05.15 at 16:55, <kirill.yukhin@gmail.com> wrote:
> Folks,
> 
> On 05 May 17:07, Jan Beulich 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.  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?
> Wanted to mention couple of points:
>   1. I agree w/ HJ: SDM is not a source of syntax
>   2. We have two product already released: ICC (2 version at the moment) and 
> GCC
>   (4.9 and 5) which use existing syntax for emitting those insns
> 
> Said that, I don't see any reason to introduce (not replace) alternative 
> operand order.

I'm confused - did you perhaps mean to say "I don't see any reason
not to introduce ..."?

Jan

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

[Kirill Yukhin]

Hello Jan,
On 26 May 09:04, Jan Beulich wrote:
> >>> On 25.05.15 at 16:55, <kirill.yukhin@gmail.com> wrote:
> >> Thoughts?
> > Wanted to mention couple of points:
> >   1. I agree w/ HJ: SDM is not a source of syntax
> >   2. We have two product already released: ICC (2 version at the moment) and 
> > GCC
> >   (4.9 and 5) which use existing syntax for emitting those insns
> > 
> > Said that, I don't see any reason to introduce (not replace) alternative 
> > operand order.
> 
> I'm confused - did you perhaps mean to say "I don't see any reason
> not to introduce ..."?
No, this is what I think.  I think that having two variants of operands order
is not good idea.

We have those products which use AVX-512:
  1. ICC (couple of versions):         uses {vreg, vreg, {RC}, GPR} order.
  2. Binutils (couple of versions):    Same.
  3. GCC (4.9, 5):                     Same.
  4. NASM (I tried last ver, 2.11.08): Same.

MASM doesn't support AVX-512 and cannot be source of Intel syntax,
but I'll try to inform them about current variant.

Finally, (I promise, I repeat it last time) as far as SDM is not a source of Intel syntax,
I see no reason to allow another order. IMO, such addition might
even increase confusion about this non-trivial stuff.

--
Thanks, K


> 
> Jan
> 

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

[Jan Beulich]

>>> On 26.05.15 at 13:24, <kirill.yukhin@gmail.com> wrote:
> Finally, (I promise, I repeat it last time) as far as SDM is not a source of 
> Intel syntax,

Which btw is something I don't really buy, for three reasons:
1) Why would it specify mnemonics (including operands) then in the
first place?
2) Other architectures explicitly use the instruction specifications as
guideline for what assemblers should accept, or even require
assemblers to behave in a certain way (see e.g. ARM ARM).
3) In the absence of any other formal definition, one ought to use
what is there instead of inventing something new.

> I see no reason to allow another order. IMO, such addition might
> even increase confusion about this non-trivial stuff.

Quite the opposite - it eliminates some confusion: Just compare

vcvtsd2ss xmm6\{k7\},xmm5,xmm4,\{rn-sae\}

and

vcvtsi2ss xmm6,xmm5,\{rn-sae\},eax

(found in the unpatched testsuite). In the former and all other
instructions (excepting the questionable ones) the rounding
specifier goes after all source operands.

Jan

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

[Mark Wielaard]

Hi,

On Thu, 2015-04-16 at 15:16 +0100, Jan Beulich wrote:
> 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.

After this went in all gdb buildbot slave builds started failing:
http://gdb-build.sergiodj.net/waterfall

../../binutils-gdb/opcodes/i386-tbl.h:76775:9: error: (near
initialization for ‘i386_optab[4370].cpu_flags.bitfield.cpuamd64’)
[-Werror=missing-field-initializers]

Did something go wrong with regenerating i386-tbl.h after commit 5db04?

Thanks,

Mark

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

[Jan Beulich]

>>> On 01.06.15 at 11:17, <mjw@redhat.com> wrote:
> Hi,
> 
> On Thu, 2015-04-16 at 15:16 +0100, Jan Beulich wrote:
>> 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.
> 
> After this went in all gdb buildbot slave builds started failing:
> http://gdb-build.sergiodj.net/waterfall 
> 
> ../../binutils-gdb/opcodes/i386-tbl.h:76775:9: error: (near
> initialization for ‘i386_optab[4370].cpu_flags.bitfield.cpuamd64’)
> [-Werror=missing-field-initializers]
> 
> Did something go wrong with regenerating i386-tbl.h after commit 5db04?

Let me check, and if needed commit a fix.

Jan

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

[Jan Beulich]

>>> On 01.06.15 at 11:17, <mjw@redhat.com> wrote:
> On Thu, 2015-04-16 at 15:16 +0100, Jan Beulich wrote:
>> 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.
> 
> After this went in all gdb buildbot slave builds started failing:
> http://gdb-build.sergiodj.net/waterfall 
> 
> ../../binutils-gdb/opcodes/i386-tbl.h:76775:9: error: (near
> initialization for ‘i386_optab[4370].cpu_flags.bitfield.cpuamd64’)
> [-Werror=missing-field-initializers]
> 
> Did something go wrong with regenerating i386-tbl.h after commit 5db04?

Fix pushed - thanks for letting me know, and sorry for the breakage.

Jan