This looks similar to Bug 356715 (http://bugs.kde.org/show_bug.cgi?id=356715), but only the first 3 bytes match. My apologies if I should have "me too'd". It appears SHRX on Debian 8.2/i686 is giving Valgrind some trouble. $ valgrind ./cryptest.exe v ==30929== Memcheck, a memory error detector ==30929== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==30929== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==30929== Command: ./cryptest.exe v ==30929== vex x86->IR: unhandled instruction bytes: 0xC4 0xE2 0x7B 0xF7 ==30929== valgrind: Unrecognised instruction at address 0x811c731. ... And: (gdb) disass /r 0x811c731 Dump of assembler code for function CryptoPP::Rijndael::Base::UncheckedSetKey(unsigned char const*, unsigned int, CryptoPP::NameValuePairs const&): 0x0811c720 <+0>: 55 push %ebp 0x0811c721 <+1>: b8 02 00 00 00 mov $0x2,%eax 0x0811c726 <+6>: 89 e5 mov %esp,%ebp 0x0811c728 <+8>: 57 push %edi 0x0811c729 <+9>: 56 push %esi 0x0811c72a <+10>: 53 push %ebx 0x0811c72b <+11>: 83 ec 4c sub $0x4c,%esp 0x0811c72e <+14>: 8b 4d 08 mov 0x8(%ebp),%ecx 0x0811c731 <+17>: c4 e2 7b f7 45 10 shrx %eax,0x10(%ebp),%eax 0x0811c737 <+23>: 8b 75 08 mov 0x8(%ebp),%esi 0x0811c73a <+26>: 8d 50 06 lea 0x6(%eax),%edx 0x0811c73d <+29>: 83 c0 07 add $0x7,%eax 0x0811c740 <+32>: 8d 59 10 lea 0x10(%ecx),%ebx Reproducible: Always
The processor is a Core-i5-5200U. The Core-i5-5200U was purchased to test the RDRAND and RDSEED instructions. It looks like SHRX is part of BMI2 (http://en.wikipedia.org/wiki/Bit_Manipulation_Instruction_Sets). BMI2 instructions look like a fairly recent addition. Wikipedia says its part of Haswell (announced in July 2013), and this is a Broadwell processor (June 2015).
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.