Hello, For gcc you may have a look onto the -march and -mtune options in the man pages to restrict the generated instruction set to an older CPU type. Your i7 may be detected as corei7-avx while your i3 may be detected as an older type.
There are also a lot of options to selectively disable specific features, e.g. -mno-avx2, -mno-sse4.2, ... in the man pages. Regards Christoph Niethammer -- Christoph Niethammer High Performance Computing Center Stuttgart (HLRS) Nobelstrasse 19 70569 Stuttgart Tel: ++49(0)711-685-87203 email: nietham...@hlrs.de http://www.hlrs.de/people/niethammer ----- Ursprüngliche Mail ----- Von: "Brian Budge" <brian.bu...@gmail.com> An: "Adam.Jirasek" <adam.jira...@gmail.com> CC: valgrind-users@lists.sourceforge.net Gesendet: Freitag, 7. Februar 2014 23:43:11 Betreff: Re: [Valgrind-users] Intel i3 vs.Intel I7 - unhandled instruction bytes: 0xC4 0xC2 0x79 0xF7 0xC9 0x89 0x45 0x80 On Fri, Feb 7, 2014 at 3:28 PM, Adam.Jirasek <adam.jira...@gmail.com> wrote: > Hello > > I have a C program which I routinely test with valgrind. > The platform is Intel i3 dual core, gcc-4.7.3. and for all my tests > valgrind did not give any warning when I started my program > > > Now I updated to a new computer > Intel i7 4th generation, gcc-4.7.3 and when I start valgrind with my > code I get: > > valgrind --tool=memcheck --trace-children=yes > --vex-iropt-register-updates=allregs-at-mem-access --leak-check=full > --leak-resolution=high --show-reachable=yes --track-origins=yes > ../../Source/Server_Main.out --port 31000 --input_file > Definition_File_PDT_Modes --show > ==28771== Memcheck, a memory error detector > ==28771== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. > ==28771== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info > ==28771== Command: ../../Source/Server_Main.out --port 31000 > --input_file Definition_File_PDT_Modes --show > ==28771== > vex amd64->IR: unhandled instruction bytes: 0xC4 0xC2 0x79 0xF7 0xC9 > 0x89 0x45 0x80 > vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=1 > vex amd64->IR: VEX=1 VEX.L=0 VEX.nVVVV=0x0 ESC=0F38 > vex amd64->IR: PFX.66=1 PFX.F2=0 PFX.F3=0 > ==28771== valgrind: Unrecognised instruction at address 0x400da4b. > ==28771== at 0x400DA4B: _dl_important_hwcaps (in /lib64/ld-2.17.so) > ==28771== by 0x4007D8E: _dl_init_paths (in /lib64/ld-2.17.so) > ==28771== by 0x4003128: dl_main (in /lib64/ld-2.17.so) > ==28771== by 0x40152E7: _dl_sysdep_start (in /lib64/ld-2.17.so) > ==28771== by 0x4004EA4: _dl_start (in /lib64/ld-2.17.so) > ==28771== by 0x4001647: ??? (in /lib64/ld-2.17.so) > ==28771== by 0x5: ??? > ==28771== by 0x7FF000056: ??? > ==28771== by 0x7FF000073: ??? > ==28771== by 0x7FF00007A: ??? > ==28771== by 0x7FF000080: ??? > ==28771== by 0x7FF00008D: ??? > ==28771== Your program just tried to execute an instruction that Valgrind > ==28771== did not recognise. There are two possible reasons for this. > ==28771== 1. Your program has a bug and erroneously jumped to a non-code > ==28771== location. If you are running Memcheck and you just saw a > ==28771== warning about a bad jump, it's probably your program's fault. > ==28771== 2. The instruction is legitimate but Valgrind doesn't handle it, > ==28771== i.e. it's Valgrind's fault. If you think this is the case or > ==28771== you are not sure, please let us know and we'll try to fix it. > ==28771== Either way, Valgrind will now raise a SIGILL signal which will > ==28771== probably kill your program. > ==28771== > ==28771== Process terminating with default action of signal 4 (SIGILL) > ==28771== Illegal opcode at address 0x400DA4B > ==28771== at 0x400DA4B: _dl_important_hwcaps (in /lib64/ld-2.17.so) > ==28771== by 0x4007D8E: _dl_init_paths (in /lib64/ld-2.17.so) > ==28771== by 0x4003128: dl_main (in /lib64/ld-2.17.so) > ==28771== by 0x40152E7: _dl_sysdep_start (in /lib64/ld-2.17.so) > ==28771== by 0x4004EA4: _dl_start (in /lib64/ld-2.17.so) > ==28771== by 0x4001647: ??? (in /lib64/ld-2.17.so) > ==28771== by 0x5: ??? > ==28771== by 0x7FF000056: ??? > ==28771== by 0x7FF000073: ??? > ==28771== by 0x7FF00007A: ??? > ==28771== by 0x7FF000080: ??? > ==28771== by 0x7FF00008D: ??? > ==28771== > ==28771== HEAP SUMMARY: > ==28771== in use at exit: 0 bytes in 0 blocks > ==28771== total heap usage: 0 allocs, 0 frees, 0 bytes allocated > ==28771== > ==28771== All heap blocks were freed -- no leaks are possible > ==28771== > ==28771== For counts of detected and suppressed errors, rerun with: -v > ==28771== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > Illegal instruction > > > > Any advice what my be causing such a warning? > Yes, you've emitted an instruction that valgrind does not handle. Searching for the same instruction string on google, I found that there was already a bug filed for this. You can try limiting your instruction set when you compile. I do not know exactly what instruction this is, but if you can determine that, you can try to get the compiler not to emit it. I notice that you're also running valgrind that only has copyright up to 2012. Maybe try the latest version? Brian ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users ------------------------------------------------------------------------------ Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
