Valgrind report: vex amd64->IR: unhandled instruction bytes: 0x66 0x48 0xF 0x3A 0x16 0xA ==5835== valgrind: Unrecognised instruction at address 0x428256. ... ==5835== Process terminating with default action of signal 4 (SIGILL) Objdump report: 428227: 48 8b 54 24 08 mov 0x8(%rsp),%rdx 42822c: 48 8b 0c 24 mov (%rsp),%rcx 428230: 49 89 c5 mov %rax,%r13 428233: 48 8b 44 24 48 mov 0x48(%rsp),%rax 428238: 4c 8b 70 08 mov 0x8(%rax),%r14 42823c: 4c 8b 38 mov (%rax),%r15 42823f: 33 c0 xor %eax,%eax 428241: 66 48 0f 6e c9 movq %rcx,%xmm1 428246: 66 0f 6c c9 punpcklqdq %xmm1,%xmm1 42824a: 66 48 0f 6e c2 movq %rdx,%xmm0 42824f: 4c 89 ea mov %r13,%rdx 428252: 66 0f 6c c0 punpcklqdq %xmm0,%xmm0 428256: 66 48 0f 3a 16 0a 00 pextrq $0x0,%xmm1,(%rdx) 42825d: 66 48 0f 3a 16 4a 10 pextrq $0x1,%xmm1,0x10(%rdx) 428264: 01 428265: 66 48 0f 3a 16 42 08 pextrq $0x0,%xmm0,0x8(%rdx) 42826c: 00 42826d: 66 48 0f 3a 16 42 18 pextrq $0x1,%xmm0,0x18(%rdx) 428274: 01 428275: 48 83 c2 20 add $0x20,%rdx 428279: 48 83 c0 02 add $0x2,%rax 42827d: 48 83 f8 04 cmp $0x4,%rax Misc: $ /usr/local/valgrind-3.5.0/bin/valgrind --version valgrind-3.5.0 $ uname -a Linux linux-1 2.6.30.5-43.fc11.x86_64 #1 SMP Thu Aug 27 21:39:52 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux Wed-22:47:25 3 0 kent@linux-1:~/Pioneer/projects/Bayes/BayesBFast_IISIBD_20090831/intel_2 $ icpc --version icpc (ICC) 11.1 20090630 Copyright (C) 1985-2009 Intel Corporation. All rights reserved.
Please post contents of /proc/cpuinfo.
Oh, it's a SSE4.1 insn, looks like. This is on a Core iSomething cpu?
I get the same bug on a Xeon 5400 (core 2) CPU: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Xeon(R) CPU E5430 @ 2.66GHz stepping : 6 cpu MHz : 2000.000 cache size : 6144 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 lahf_lm tpr_shadow vnmi flexpriority bogomips : 5319.13 clflush size : 64 cache_alignment : 64 address sizes : 38 bits physical, 48 bits virtual power management: and some more cores. My error is: ==7349== Command: ./Debug/solver-ui ==7349== vex amd64->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0xA 0xC0 0x2 ==7349== valgrind: Unrecognised instruction at address 0x41cfe4. ==7349== Your program just tried to execute an instruction that Valgrind ==7349== did not recognise. There are two possible reasons for this. ==7349== 1. Your program has a bug and erroneously jumped to a non-code ==7349== location. If you are running Memcheck and you just saw a ==7349== warning about a bad jump, it's probably your program's fault. ==7349== 2. The instruction is legitimate but Valgrind doesn't handle it, ==7349== i.e. it's Valgrind's fault. If you think this is the case or ==7349== you are not sure, please let us know and we'll try to fix it. ==7349== Either way, Valgrind will now raise a SIGILL signal which will ==7349== probably kill your program. ==7349== ==7349== Process terminating with default action of signal 4 (SIGILL) ==7349== Illegal opcode at address 0x41CFE4 ==7349== at 0x41CFE4: std::_Hashtable<std::string, std::pair<std::string const, il::type*>, std::allocator<std::pair<std::string const, il::type*> >, std::_Select1st<std::pair<std::string const, il::type*> >, std::equal_to<std::string>, std::hash<std::string>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, false, false, true>::_Hashtable(unsigned long, std::hash<std::string> const&, std::__detail::_Mod_range_hashing const&, std::__detail::_Default_ranged_hash const&, std::equal_to<std::string> const&, std::_Select1st<std::pair<std::string const, il::type*> > const&, std::allocator<std::pair<std::string const, il::type*> > const&) (hashtable_policy.h:460) ==7349== by 0x43F2D0: global constructors keyed to VarMap.cpp (unordered_map:70) ==7349== by 0x498495: ??? (in /home/tdillig/research/solver-ui/Debug/solver-ui) ==7349== by 0x49EE52: ??? (in /home/tdillig/research/solver-ui/Debug/solver-ui) ==7349== by 0x5674F2F: ??? (in /usr/lib/libgtkmm-2.4.so.1.1.0) ==7349== by 0x498424: __libc_csu_init (in /home/tdillig/research/solver-ui/Debug/solver-ui) ==7349== by 0x9EACA4F: (below main) (libc-start.c:179) ==7349== ==7349== HEAP SUMMARY: ==7349== in use at exit: 8,745 bytes in 109 blocks ==7349== total heap usage: 110 allocs, 1 frees, 9,313 bytes allocated ==7349== ==7349== LEAK SUMMARY: ==7349== definitely lost: 120 bytes in 1 blocks ==7349== indirectly lost: 0 bytes in 0 blocks ==7349== possibly lost: 3,425 bytes in 103 blocks ==7349== still reachable: 5,200 bytes in 5 blocks ==7349== suppressed: 0 bytes in 0 blocks ==7349== Rerun with --leak-check=full to see details of leaked memory ==7349== ==7349== For counts of detected and suppressed errors, rerun with: -v ==7349== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
(In reply to comment #3) > I get the same bug on a Xeon 5400 (core 2) CPU: [snipped] > vex amd64->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0xA 0xC0 0x2 No, that's a different bug because the instruction bytes are different. Yours is ROUNDSS and was implemented in VEX r1986.
The original error reported here is PEXTRQ which was implemented in VEX r1973.