http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60736
--- Comment #5 from Ian Lance Taylor <ian at airs dot com> --- This is easy enough to recreate--do you really need valgrind output? In any case, here it is. > cat foo.c #include <stdc-predef.h> > valgrind gcc/cc1 foo.c ==25367== Memcheck, a memory error detector ==25367== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==25367== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==25367== Command: gcc/cc1 foo.c ==25367== vex amd64->IR: unhandled instruction bytes: 0xF3 0x48 0xF 0xBC 0xC3 0x48 0x98 0x48 ==25367== valgrind: Unrecognised instruction at address 0x608f90. ==25367== at 0x608F90: init_ggc() (hwint.h:260) ==25367== by 0x99DDEE: toplev_main(int, char**) (toplev.c:1157) ==25367== by 0x5A3176C: (below main) (libc-start.c:226) ==25367== Your program just tried to execute an instruction that Valgrind ==25367== did not recognise. There are two possible reasons for this. ==25367== 1. Your program has a bug and erroneously jumped to a non-code ==25367== location. If you are running Memcheck and you just saw a ==25367== warning about a bad jump, it's probably your program's fault. ==25367== 2. The instruction is legitimate but Valgrind doesn't handle it, ==25367== i.e. it's Valgrind's fault. If you think this is the case or ==25367== you are not sure, please let us know and we'll try to fix it. ==25367== Either way, Valgrind will now raise a SIGILL signal which will ==25367== probably kill your program. ==25367== Invalid read of size 4 ==25367== at 0xF1CC8D: linemap_location_from_macro_expansion_p(line_maps*, unsigned int) (line-map.c:948) ==25367== by 0xF1CE2E: linemap_lookup(line_maps*, unsigned int) (line-map.c:642) ==25367== by 0x9DC257: virt_loc_aware_diagnostic_finalizer(diagnostic_context*, diagnostic_info*) (tree-diagnostic.c:111) ==25367== by 0xF02837: diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) (diagnostic.c:801) ==25367== by 0xF0357F: internal_error(char const*, ...) (diagnostic.c:1136) ==25367== by 0x99C70F: crash_signal(int) (toplev.c:337) ==25367== by 0x5A4649F: ??? (in /lib/x86_64-linux-gnu/libc-2.15.so) ==25367== by 0x608F8F: init_ggc() (hwint.h:307) ==25367== by 0x99DDEE: toplev_main(int, char**) (toplev.c:1157) ==25367== by 0x5A3176C: (below main) (libc-start.c:226) ==25367== Address 0x24 is not stack'd, malloc'd or (recently) free'd ==25367== cc1: internal compiler error: Illegal instruction ==25367== ==25367== Process terminating with default action of signal 11 (SIGSEGV) ==25367== Access not within mapped region at address 0x24 ==25367== at 0xF1CC8D: linemap_location_from_macro_expansion_p(line_maps*, unsigned int) (line-map.c:948) ==25367== by 0xF1CE2E: linemap_lookup(line_maps*, unsigned int) (line-map.c:642) ==25367== by 0x9DC257: virt_loc_aware_diagnostic_finalizer(diagnostic_context*, diagnostic_info*) (tree-diagnostic.c:111) ==25367== by 0xF02837: diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) (diagnostic.c:801) ==25367== by 0xF0357F: internal_error(char const*, ...) (diagnostic.c:1136) ==25367== by 0x99C70F: crash_signal(int) (toplev.c:337) ==25367== by 0x5A4649F: ??? (in /lib/x86_64-linux-gnu/libc-2.15.so) ==25367== by 0xF1CC8C: linemap_location_from_macro_expansion_p(line_maps*, unsigned int) (line-map.c:948) ==25367== by 0xF1CE2E: linemap_lookup(line_maps*, unsigned int) (line-map.c:642) ==25367== by 0x9DC257: virt_loc_aware_diagnostic_finalizer(diagnostic_context*, diagnostic_info*) (tree-diagnostic.c:111) ==25367== by 0xF02837: diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) (diagnostic.c:801) ==25367== by 0xF0357F: internal_error(char const*, ...) (diagnostic.c:1136) ==25367== If you believe this happened as a result of a stack ==25367== overflow in your program's main thread (unlikely but ==25367== possible), you can try to increase the size of the ==25367== main thread stack using the --main-stacksize= flag. ==25367== The main thread stack size used in this run was 67108864. ==25367== ==25367== HEAP SUMMARY: ==25367== in use at exit: 22,246 bytes in 10 blocks ==25367== total heap usage: 266 allocs, 256 frees, 45,231 bytes allocated ==25367== ==25367== LEAK SUMMARY: ==25367== definitely lost: 31 bytes in 1 blocks ==25367== indirectly lost: 0 bytes in 0 blocks ==25367== possibly lost: 0 bytes in 0 blocks ==25367== still reachable: 22,215 bytes in 9 blocks ==25367== suppressed: 0 bytes in 0 blocks ==25367== Rerun with --leak-check=full to see details of leaked memory ==25367== ==25367== For counts of detected and suppressed errors, rerun with: -v ==25367== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 2 from 2) Segmentation fault (core dumped)
