https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78192
Bug ID: 78192 Summary: extract from vector registers to int results in wrong data order Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: meissner at gcc dot gnu.org Reporter: acsawdey at gcc dot gnu.org CC: wschmidt at gcc dot gnu.org Target Milestone: --- Target: rs6000 ppc64le power9 Tested with trunk 241701, running on power8 ppc64le compiling for power9 ppc64le. gcc.c-torture/execute/simd-1.c is failing and it appears that the extraction from vector to int registers is not happening in the right order. 7 typedef int __attribute__((mode(SI))) __attribute__((vector_size (16))) vecint; 8 typedef int __attribute__((mode(SI))) siint; 9 10 vecint i = { 150, 100, 150, 200 }; 11 vecint j = { 10, 13, 20, 30 }; 12 vecint k; 13 14 union { 15 vecint v; 16 siint i[4]; 17 } res; 18 19 /* This should go away once we can use == and != on vector types. */ 20 void 21 verify (siint a1, siint a2, siint a3, siint a4, 22 siint b1, siint b2, siint b3, siint b4) 23 { 24 if (a1 != b1 25 || a2 != b2 26 || a3 != b3 27 || a4 != b4) 28 abort (); 29 } 30 31 int 32 main () 33 { 34 k = i + j; 35 res.v = k; 0x00000000100006f0 <main+44>: lxv vs63,0(r9) 0x00000000100006f4 <main+48>: lxv vs62,16(r9) 0x00000000100006f8 <main+52>: vadduwm v0,v31,v30 0x00000000100006fc <main+56>: nop 0x0000000010000700 <main+60>: addi r30,r2,-32400 0x0000000010000704 <main+64>: stxv vs32,0(r30) 0x0000000010000708 <main+68>: nop 0x000000001000070c <main+72>: addi r31,r2,-32384 0x0000000010000710 <main+76>: stxv vs32,0(r31) 0x0000000010000714 <main+80>: xxextractuw vs33,vs32,12 0x0000000010000718 <main+84>: mfvrwz r6,v1 0x000000001000071c <main+88>: mfvrwz r5,v0 0x0000000010000720 <main+92>: xxextractuw vs33,vs32,4 0x0000000010000724 <main+96>: mfvrwz r4,v1 0x0000000010000728 <main+100>: xxextractuw vs32,vs32,0 0x000000001000072c <main+104>: mfvrwz r3,v0 0x0000000010000730 <main+108>: li r10,230 0x0000000010000734 <main+112>: li r9,170 0x0000000010000738 <main+116>: li r8,113 0x000000001000073c <main+120>: li r7,160 0x0000000010000740 <main+124>: extsw r6,r6 0x0000000010000744 <main+128>: extsw r5,r5 0x0000000010000748 <main+132>: extsw r4,r4 0x000000001000074c <main+136>: extsw r3,r3 0x0000000010000750 <main+140>: bl 0x10000684 <verify+8> at 0x00000000100006fc the vector register results look ok: (gdb) p $vs32 $22 = {uint128 = 0x000000e6000000aa00000071000000a0, v2_double = {2.3978552445812627e-312, 4.8805903200600379e-312}, v4_float = {2.24207754e-43, 1.58346726e-43, 2.38220739e-43, 3.22298647e-43}, v4_int32 = { 160, 113, 170, 230}, v8_int16 = {160, 0, 113, 0, 170, 0, 230, 0}, v16_int8 = {-96, 0, 0, 0, 113, 0, 0, 0, -86, 0, 0, 0, -26, 0, 0, 0}} (gdb) p $vs62 $23 = {uint128 = 0x0000001e000000140000000d0000000a, v2_double = {2.7585945287489197e-313, 6.3659873738839482e-313}, v4_float = {1.40129846e-44, 1.821688e-44, 2.80259693e-44, 4.20389539e-44}, v4_int32 = {10, 13, 20, 30}, v8_int16 = {10, 0, 13, 0, 20, 0, 30, 0}, v16_int8 = {10, 0, 0, 0, 13, 0, 0, 0, 20, 0, 0, 0, 30, 0, 0, 0}} (gdb) p $vs63 $24 = {uint128 = 0x000000c8000000960000006400000096, v2_double = {2.1219957917063708e-312, 4.2439915826716431e-312}, v4_float = {2.1019477e-43, 1.40129846e-43, 2.1019477e-43, 2.80259693e-43}, v4_int32 = {150, 100, 150, 200}, v8_int16 = {150, 0, 100, 0, 150, 0, 200, 0}, v16_int8 = {-106, 0, 0, 0, 100, 0, 0, 0, -106, 0, 0, 0, -56, 0, 0, 0}} at 0x0000000010000730 the extraction into gprs is incorrect: (gdb) p $r3 $14 = 230 (gdb) p $r4 $15 = 170 (gdb) p $r5 $16 = 170 (gdb) p $r6 $17 = 160