valgrind 3.11.0 (tar.bz2) built from source on CentOS release 6.7 (Final) seg-faults on the following AVX2 instructions: _mm256_store_ps((dest + i), _mm256_cvtph_ps(_mm_load_si128((__m128i*)(cube + i)))); compiler: icpc (ICC) 15.0.2 20150121 compiler invokation: icpc -g -O3 -xCORE-AVX2 -mcmodel large
c4 e2 7d 13 04 4a vcvtph2ps (%rdx,%rcx,2),%ymm0
Hmm. I see that (even in 3.14.0) we advertise the F16C extension in the simulated CPUID results, but don't actually implement the instruction.
I see the same kind of behaviour but different instruction bytes when using massif with 3.15.0 on a piece of code that is inside the GNU Fortran runtime. Is there anything I can do? Thanks ==130871== Massif, a heap profiler ==130871== Copyright (C) 2003-2017, and GNU GPL'd, by Nicholas Nethercote ==130871== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==130871== Command: ./mld_d_pde3d ==130871== vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0x7D 0x28 0xEF 0xC0 0x48 0x83 0x3D 0x4B vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==81517== valgrind: Unrecognised instruction at address 0x5208f57. ==81517== at 0x5208F57: ??? (in /gpfs/apps/MN4/GCC/7.2.0/lib64/libgfortran.so.4.0.0) ==81517== by 0x52095FB: ??? (in /gpfs/apps/MN4/GCC/7.2.0/lib64/libgfortran.so.4.0.0) ==81517== by 0x508BB47: ??? (in /gpfs/apps/MN4/GCC/7.2.0/lib64/libgfortran.so.4.0.0) ==81517== by 0x400ECB9: call_init.part.0 (in /lib64/ld-2.22.so) ==81517== by 0x400EDA2: _dl_init (in /lib64/ld-2.22.so) ==81517== by 0x4001229: ??? (in /lib64/ld-2.22.so)
Please don't hijack unrelated bugs - every unsupported instruction is different and the one you quote has an entirely different byte stream to this one. Your byte stream looks like it matches bug https://bugs.kde.org/show_bug.cgi?id=409999 so that is the place to discuss it.
This is VCVTPH2PS and is fixed in the 3.15.0 release.
*** Bug 415382 has been marked as a duplicate of this bug. ***
*** Bug 427057 has been marked as a duplicate of this bug. ***
This should be fixed in valgrind 3.15.0 by: commit 472b067e39a11a47ae3fa7cd7d3142558f78969d Author: Julian Seward <jseward@acm.org> Date: Sun Mar 17 21:41:42 2019 +0100 amd64: Implement RDRAND, VCVTPH2PS and VCVTPS2PH. Bug 398870 - Please add support for instruction vcvtps2ph Bug 353370 - RDRAND amd64->IR: unhandled instruction bytes: 0x48 0xF 0xC7 0xF0 This commit implements: * amd64 RDRAND instruction, on hosts that have it. * amd64 VCVTPH2PS and VCVTPS2PH, on hosts that have it. The presence/absence of these on the host is now reflected in the CPUID results returned to the guest. So code that tests for these features in CPUID and acts accordingly should "just work". * New test cases, none/tests/amd64/rdrand and none/tests/amd64/f16c. These are built if the host's assembler can handle them, in the usual way.