Application compiled with Intel Compiler 18.1 generates calls to "_intel_fast_memcpy" which triggers this assertion failure in Valgrind. Valgrind log: --00:00:02:34.797 2713-- REDIR: 0x9feac80 (_intel_fast_memcpy) redirected to 0xb774be0 (_intel_fast_memcpy) vex amd64->IR: unhandled instruction bytes: 0x66 0xF 0x38 0x23 0xC0 0xF3
Wierd. I wonder why we don't support this, given that support for AVX2 is generally available in V.
Should I try to put together a test case?
(In reply to Patrick J. LoPresti from comment #2) > Should I try to put together a test case? Yes, please. I have had a look around and I am mystified. PMOVSXWD appears to be both implemented and tested (in none/tests/amd64/{sse4-64.c, avx-1.c}) so I'm not sure why it's failing for you. Or more specifically, which of the innumerable variants of it might be failing.
I would add: given that you have failing bytes 0x66 0xF 0x38 0x23, this is an SSE4 variant, not an AVX variant -- since there's no C2/C3 (VEX) prefix present.
I made a test case using the failing bytes you sent, as below, and it runs ok with the trunk. int main ( void ) { // 66 0f 38 23 c0 pmovsxwd %xmm0,%xmm0 __asm__ __volatile__(".byte 0x66, 0xF, 0x38, 0x23, 0xC0" :::"cc","memory"); return 0; }
I am so sorry, Julian. Although I compiled Valgrind from trunk, one of my coworkers did not follow my instructions to use it and did not tell me this when he reported the failure. I should have looked at the header in the log file more carefully. I apologize again for wasting your time.
(In reply to Patrick J. LoPresti from comment #6) It's no problem! I am just happy that I can cross this off my list of stuff-to-be-fixed. If only all bugs were this easy to fix!