> vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0x16 > ==18426== at 0x804BE18: manhattan(unsigned char const*, unsigned char const*) (emmintrin.h:208) That's "PEXTRD r/m32, xmm2, Ib" which extracts a 32-bit wide, 32-bit aligned, known-in-advance slice from xmm2, then places the slice into a general register or memory location. The opcode is from the SSE4.1 extensions. vex-amd64 handles this case, but vex-x86 omits it (and should not). In general x86 lacks the REX prefix byte (and there are no 64-bit general registers), but otherwise has mostly the same SSEx.y opcodes as amd64.
Same goes for the SSE4 instruction 0x66 0xF 0x3A 0x9 (_mm_ceil_pd), both in x86 and x86_64 (amd64). System is a MBP 13" with an i7 running OS X 10.6.8 , app is compiled with gcc-4.2 with the -msse4 flag. I haven't tried, but I'm guessing more SSE4 instructions are concerned, why not just add them all? SSE4 isn't exactly the latest and hottest addition...
SSSE3 is the most recent insn set extension support in 32 bit mode. There are no plans to support anything more recent for 32 bit. For 64 bit we support everything up to and including AVX. There has been a lot of work recently on this. Can you re-check the trunk and see if it is still broken for you? IIUC we have full coverage in 64 bit mode, or very close to it.
Indeed, I haven't found any more SSE-related issues with svn-trunk. However, it tells me valgrind: the 'impossible' happened: thread_create() unimplemented [...] sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==56560== at 0x100129D7A: mach_msg_trap (in /usr/lib/libSystem.B.dylib) ==56560== by 0x1001FB786: thread_create (in /usr/lib/libSystem.B.dylib) ==56560== by 0x1002054E8: pthread_create_suspended_np (in /usr/lib/libSystem.B.dylib) ==56560== by 0x100002263: CreateThread (msemul.h:407) ==56560== by 0x100011595: Thread::Start(void*) (Thread.h:35) ==56560== by 0x10000FFFB: main (threadTest.cpp:130) Is it supposed to do that?
*** Bug 306360 has been marked as a duplicate of this bug. ***
We've got a user reporting a similar issue for unhandled instructions "0x66 0xF 0x3A 0x22". Only the last byte differs, and I'm guessing its the same or nearly the same issue. I don't know the compiler. Also see https://groups.google.com/d/msg/cryptopp-users/rwRSMrxJVcw/68BESEbCAQAJ. Others have reported the same unhandled instructions "0x66 0xF 0x3A 0x22". It looks like the compiler is Clang. Also see https://github.com/miloyip/rapidjson/issues/266.
Please do not revive old bugs. Leave them R.I.P. :-) If this is a new problem for you, please report a new bug as per http://valgrind.org/support/bug_reports.html including all the required details.
(In reply to Ivo Raisr from comment #6) > Please do not revive old bugs. Leave them R.I.P. :-) > > If this is a new problem for you, please report a new bug as per > http://valgrind.org/support/bug_reports.html > including all the required details. Thanks Iva. The bug is still open. How do we know when to add to an existing bug report, and open a new one?