https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71201
--- Comment #2 from acsawdey at gcc dot gnu.org ---
>From what I can see, the left-shifted piece of this is not being computed
properly. Looks like maybe register allocation is getting confused and not
treating v17/vs49 as the same thing? Hard to follow this with all these xxlor
moving stuff around.
wc[0] = 0x73;
for (t = 0; t < 256; ++t)
rc[t] = (wc[t] >> 5) | (wc[t] << (sizeof (wc[0]) * __CHAR_BIT__ - 5));
rc[0] ends up with value 3, which is 0x73>>5.
Here's the trail of breadcrumbs I tried to follow forward
/home/sawdey/src/gcc/pre-gcc7/pre-gcc7/gcc/testsuite/gcc.c-torture/execute/pr56866.c:31
10001924: fd ff a2 3f addis r29,r2,-3
10001928: fd ff 62 3d addis r11,r2,-3
1000192c: 59 1d e1 f7 lxv vs63,7504(r1)
10001930: e9 1d 21 f5 lxv vs41,7648(r1)
10001934: 4c 03 60 11 vspltish v11,0
10001938: 8c 03 83 11 vspltisw v12,3
1000193c: 70 be fd 38 addi r7,r29,-16784
10001940: 80 be 8b 3b addi r28,r11,-16768
10001944: 21 1d 41 f4 lxv vs2,7456(r1) load wc[t]
here
10001948: 21 1d 61 f4 lxv vs3,7456(r1)
100019a0: d6 38 4b f0 xxperm vs2,vs43,vs39 but then
write over it here?
100019a4: d6 50 6b f0 xxperm vs3,vs43,vs42
10001eac: 29 1d 21 f6 lxv vs49,7456(r1)
load wc[t] again here
10001f04: 04 fa b1 10 vsrb v5,v17,v31
shift right piece now in vs37
10001f90: 0e 18 24 12 vpkuhum v17,v4,v3 write
over v17/vs49
10002000: 96 8c d1 f3 xxlor vs30,vs49,vs49 trying
to copy wc[t] to vs30? It's 0 here already
