GCC says this is just a "vmovdqu" instruction. It gets emitted by ICC 13 under circumstances that I do not fully understand.
I meant "GDB" not "GCC" obviously.
I can't reproduce this. Are you sure this is right? I tried thusly: int main ( void ) { __asm__ __volatile__( ".byte 0xC5, 0xFA, 0x7F, 0x45, 0x80, 0xC5, 0xFA, 0x7F, 0x4D, 0x90" ::: "cc","memory"); return 0; } giving 00000000004004f6 <main>: 4004f6: c5 fa 7f 45 80 vmovdqu %xmm0,-0x80(%rbp) 4004fb: c5 fa 7f 4d 90 vmovdqu %xmm1,-0x70(%rbp) 400500: b8 00 00 00 00 mov $0x0,%eax 400505: c3 retq 400506: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1) 40050d: 00 00 00 (sure, there are 2 complete insns there, but it doesn't matter) and although it segfaults (as it does natively), it runs correctly through the front end: $ ./zzz6 Segmentation fault (core dumped) $ v312BRANCH ./zzz6 ==5911== Memcheck, a memory error detector ==5911== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==5911== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info ==5911== Command: ./zzz6 ==5911== ==5911== ==5911== Process terminating with default action of signal 11 (SIGSEGV) ==5911== Bad permissions for mapped region at address 0x400490 ==5911== at 0x4004F6: main (zzz6.c:3) ==5911== ==5911== HEAP SUMMARY: ==5911== in use at exit: 0 bytes in 0 blocks ==5911== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==5911== ==5911== All heap blocks were freed -- no leaks are possible ==5911== ==5911== For counts of detected and suppressed errors, rerun with: -v ==5911== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Segmentation fault (core dumped)
Well, that is weird... I am not making it up :-) I was using the 3.12.0 release. Is it possible this has been fixed in SVN? I will check, but probably not until next week. Thanks, Julian
Are you running this test on a machine whose CPUID says that AVX isn't supported? Does the test actually run natively on the machine? I'm pretty sure VEX will decline to decode the insn if the surrounding Valgrind tells it this is not an AVX capable cpu. That would explain it.
Sorry, Julian, my mistake. Yes, I was running on a RHEL 5.x system whose kernel does not enable AVX support. When run outside Valgrind it gets "illegal instruction" (of course). Sorry again for the bogus report.