Bug 356715

Summary: vex amd64->IR: unhandled instruction bytes: 0xC4 0xE2 0x7D 0x13 0x4 0x4A 0xC5 0xFC
Product: [Developer tools] valgrind Reporter: Christopher Zapart <chris.zapart>
Component: generalAssignee: Julian Seward <jseward>
Status: RESOLVED FIXED    
Severity: critical CC: filippone.salvatore, goffinet.francois, mark, the.true.nathan.mills, tom
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Christopher Zapart 2015-12-15 05:56:45 UTC 
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
Comment 1 Julian Seward 2016-07-20 17:35:19 UTC 
c4 e2 7d 13 04 4a    	vcvtph2ps (%rdx,%rcx,2),%ymm0
Comment 2 Julian Seward 2018-10-17 12:24:47 UTC 
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.
Comment 3 filippone.salvatore 2019-07-29 10:27:30 UTC 
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)
Comment 4 Tom Hughes 2019-07-29 11:57:09 UTC 
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.
Comment 5 Tom Hughes 2019-12-21 00:26:54 UTC 
This is VCVTPH2PS and is fixed in the 3.15.0 release.
Comment 6 Tom Hughes 2019-12-21 00:27:03 UTC 
*** Bug 415382 has been marked as a duplicate of this bug. ***
Comment 7 Mark Wielaard 2021-02-21 00:22:46 UTC 
*** Bug 427057 has been marked as a duplicate of this bug. ***
Comment 8 Mark Wielaard 2021-02-21 00:26:26 UTC 
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.