When running my program with Valgrind & memcheck, it fails with an unhandled instruction message: vex amd64->IR: unhandled instruction bytes: 0xC5 0x79 0xD6 0xC0 0x4C 0x8D 0x9C 0x24 0xA0 0x2 vex amd64->IR: REX=0 REX.W=0 REX.R=1 REX.X=0 REX.B=0 vex amd64->IR: VEX=1 VEX.L=0 VEX.nVVVV=0x0 ESC=0F vex amd64->IR: PFX.66=1 PFX.F2=0 PFX.F3=0 ==137781== valgrind: Unrecognised instruction at address 0x4cf081. ==137781== at 0x4CF081: _mm_set_epi64x (emmintrin.h:595) ==137781== by 0x4CF081: _mm_set_epi64 (emmintrin.h:601) ==137781== by 0x4CF081: _mm_loadl_epi64 (emmintrin.h:712) It occurs with Valgrind 3.22 built from source (commit 97508f5561756a43f054c1d8e06c3e318124c9c3) but also with 3.19 from Ubuntu repositories. The program is compiled using GCC 13.1.0, and executed on the same machine. Passing -v shows: Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-lzcnt-rdtscp-sse3-ssse3-avx-avx2-bmi-f16c-rdrand-rdseed.
I also encounted this bug and created a simple repro. However, after building from the git head I see that the problem is now fixed. I'm guessing the fix arrived in commit 10a22445d747817932692b1c1ee3faa726121cb4 "Implement VMOVQ xmm1, xmm2/m64". The repro was actually pretty similar to one of the test cases in that commit. For the sake of completeness I've included the repro below, which gives a SIGILL up to and including valgrind 3.23.0. From my testing, it only fails when moving from a register in the xmm8-xmm15 range to the xmm0-xmm7 range. Other combinations (8-15 to 8-15 and 0-7 to 0-15) worked fine. The bytes in the original report (0xC5 0x79 0xD6 0xC0) correspond to "vmovq xmm0,xmm8" according to https://defuse.ca/online-x86-assembler.htm which seems to be using Intel argument ordering (DST, SRC) so a move from xmm8 to xmm0. void foo() { asm volatile( "vmovq %%xmm8, %%xmm7" :::); } int main() { foo(); return 1; }
I just did a quick test and agree that this is now fixed.