I'm working on a Fedroa 22 VM. The host is Mac OS X with an i5. When attempting to verify there are no apparent memory bugs: ... vex x86->IR: unhandled instruction bytes: 0xC5 0xFA 0x6F 0x2 ==15766== valgrind: Unrecognised instruction at address 0x8137fc1. ==15766== at 0x8137FC1: begin (secblock.h:484) ==15766== by 0x8137FC1: TEA::Base::UncheckedSetKey(unsigned char const*, unsigned int, NameValuePairs const&) (tea.cpp:16) ==15766== by 0x80E5C0F: SimpleKeyingInterface::SetKey(unsigned char const*, unsigned int, NameValuePairs const&) (cryptlib.cpp:108) ==15766== by 0x809CEC5: ECB_OneWay::SetKey(unsigned char const*, unsigned int, NameValuePairs const&) (modes.h:200) ==15766== by 0x80BAB5D: TestSymmetricCipher(map<string, string, less<string>, allocator<pair<string const, string> > >&, NameValuePairs const&) (datatest.cpp:368) ==15766== by 0x80BF02E: TestDataFile(string const&, NameValuePairs const&, unsigned int&, unsigned int&) (datatest.cpp:751) ==15766== by 0x80BF196: TestDataFile(string const&, NameValuePairs const&, unsigned int&, unsigned int&) (datatest.cpp:763) ==15766== by 0x80BF533: RunTestDataFile(char const*, NameValuePairs const&, bool) (datatest.cpp:798) ==15766== by 0x8080E95: main (test.cpp:300) ==15766== Your program just tried to execute an instruction that Valgrind ==15766== did not recognise. There are two possible reasons for this. ==15766== 1. Your program has a bug and erroneously jumped to a non-code ==15766== location. If you are running Memcheck and you just saw a ==15766== warning about a bad jump, it's probably your program's fault. ==15766== 2. The instruction is legitimate but Valgrind doesn't handle it, ==15766== i.e. it's Valgrind's fault. If you think this is the case or ==15766== you are not sure, please let us know and we'll try to fix it. ==15766== Either way, Valgrind will now raise a SIGILL signal which will ==15766== probably kill your program. ==15766== ==15766== Process terminating with default action of signal 4 (SIGILL) ==15766== Illegal opcode at address 0x8137FC1 ==15766== at 0x8137FC1: begin (secblock.h:484) I have not been able to produce a minimal test case, but it happens regularly under Fedora 22 (i686 and x86_64) for this project. It looks like the offending instruction is vmovdqu: $ objdump -d cryptest.exe | grep "c5 fa 6f 02" 810bf98: c5 fa 6f 02 vmovdqu (%edx),%xmm0 ****** I'm also seeing a vzeroupper when disassembling (it may or may not cause problems, too): ... 0x0817b410 <+1392>: mov %eax,%ebx 0x0817b412 <+1394>: vzeroupper 0x0817b415 <+1397>: jmp 0x817b3ff <HuffmanEncoder::Initialize(unsigned int const*, unsigned int)+1375> ****** GCC has gotten very aggressive with respect to vectorizations. I've even seen it use SSE4 for memcmp's.
That's an AVX instruction, which isn't supported by the x86 (32-bit) front end. x86 (32-bit) only supports up to SSSE3. I suggest you move to 64-bit x86 instead, which supports up to and including AVX2.
(In reply to Julian Seward from comment #1) > That's an AVX instruction, which isn't supported by the x86 (32-bit) front > end. > x86 (32-bit) only supports up to SSSE3. I suggest you move to 64-bit x86 > instead, > which supports up to and including AVX2. Something sounds amiss. We test under both i686 and x86_64. If vmovdqu is x86_64, then it seems like the test program should SIGILL rather than complete successfully.
I think we might be talking at cross purposes. Sure, the silicon supports VMOVDQU (and other AVX insns) in both 32- and 64-bit modes. What I meant is, Valgrind doesn't; 32-bit support doesn't extend beyond SSSE3. If you want to run AVX code on Valgrind then you need to do it in a 64-bit process.
(In reply to Julian Seward from comment #3) > I think we might be talking at cross purposes. Sure, the silicon supports > VMOVDQU > (and other AVX insns) in both 32- and 64-bit modes. What I meant is, > Valgrind > doesn't; 32-bit support doesn't extend beyond SSSE3. If you want to run AVX > code > on Valgrind then you need to do it in a 64-bit process. Oh, my bad. Yes, I was disconnected. Sorry about that.