https://bugs.kde.org/show_bug.cgi?id=391148
--- Comment #3 from Mario Salazar de Torres <mario.s...@gmail.com> --- Created attachment 114656 --> https://bugs.kde.org/attachment.cgi?id=114656&action=edit Patch for the issue Tracking the issue I noted that hex dissasembly for vmovq xmm[8-15], xmm[0-7] is matches the following pattern: 0xC5 0x79 0xD6 0xC[0-7] The last value states which register is the source, being the register xmm[value+8]. After analyzing the problem I noted that it was caused as the VEX standard was upgraded to add new XMM registers (from xmm8 to xmm15) and as Intel standard defined only 3bits to indicate both source and destination register they had to add a new VEX opcode in order to operate with the new registers. Whenever you perform a vmovq xmm[0-7], xmm[0-7] instruction the opcode is 0x7E but instead If you perform vmovq xmm[8-15], xmm[0-7] the opcode is 0xD6. Thing is D6 VEX opcode apparently were previously used but not having an XMM register as a source, so within the code that was not handled as by that time there was no test case. So the solution is as easy as implement this specific case , but adding 8 to the source register. I attach a patch for the issue. It would be great If you could tell me If it's consistent. So far the patch is working for me. -- You are receiving this mail because: You are watching all bug changes.
