Created attachment 31403 [details] Preprocessed source Attached testcase randomly fails to compile. Following valgrind error was obtained on x86_64-pc-linux-gnu: $ valgrind /ssd/uros/gcc-build/gcc/cc1plus -g -O2 -std=gnu++0x -fpreprocessed -quiet stdc++.ii ==10906== Memcheck, a memory error detector ==10906== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==10906== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==10906== Command: /ssd/uros/gcc-build/gcc/cc1plus -g -O2 -std=gnu++0x -fpreprocessed -quiet stdc++.ii ==10906== ==10906== Invalid read of size 2 ==10906== at 0x87F8FB: rtl_for_decl_init(tree_node*, tree_node*) (dwarf2out.c:15183) ==10906== by 0x88F2F1: tree_add_const_value_attribute(die_struct*, tree_node*) (dwarf2out.c:15814) ==10906== by 0x8944B4: gen_variable_die(tree_node*, tree_node*, die_struct*) (dwarf2out.c:18769) ==10906== by 0x896319: gen_decl_die(tree_node*, tree_node*, die_struct*) (dwarf2out.c:20403) ==10906== by 0x89C2AC: declare_in_namespace(tree_node*, die_struct*) (dwarf2out.c:20179) ==10906== by 0x8962F1: gen_decl_die(tree_node*, tree_node*, die_struct*) (dwarf2out.c:20390) ==10906== by 0xB4952C: emit_debug_global_declarations(tree_node**, int) (toplev.c:532) ==10906== by 0x5607B0: wrapup_globals_for_namespace(tree_node*, void*) (decl.c:883) ==10906== by 0x55D81B: walk_namespaces_r(tree_node*, int (*)(tree_node*, void*), void*) (decl.c:850) ==10906== by 0x55D835: walk_namespaces_r(tree_node*, int (*)(tree_node*, void*), void*) (decl.c:853) ==10906== by 0x62C81F: cp_write_global_declarations() (decl2.c:4448) ==10906== by 0xB4876C: compile_file() (toplev.c:561) ==10906== Address 0x101 is not stack'd, malloc'd or (recently) free'd ==10906== In file included from /ssd/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/complex.h:36:0, from /home/uros/gcc-svn/trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/stdc++.cc:30: /usr/include/complex.h:112:1: internal compiler error: Segmentation fault __END_DECLS ^ Please submit a full bug report, ...
On a related note, without -std=gnu++0x: $ /ssd/uros/gcc-build/gcc/cc1plus -g -O2 -fpreprocessed -quiet stdc++.ii In file included from /ssd/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/stl_pair.h:59:0, from /ssd/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:64, from /ssd/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/char_traits.h:39, from /ssd/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/ios:40, from /ssd/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/istream:38, from /ssd/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:38, from /ssd/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/complex:45, from /ssd/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/ccomplex:38, from /home/uros/gcc-svn/trunk/libstdc++-v3/include/precompiled/stdc++.h:52: /ssd/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/move.h: In instantiation of ‘void std::swap(_Tp&, _Tp&) [with _Tp = std::thread::id]’: /ssd/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/thread:158:33: required from here /ssd/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/move.h:176:11: internal compiler error: in type_has_trivial_fn, at cp/method.c:435 __a = _GLIBCXX_MOVE(__b); ^ 0x6b2763 type_has_trivial_fn /home/uros/gcc-svn/trunk/gcc/cp/method.c:435 0x557321 build_over_call /home/uros/gcc-svn/trunk/gcc/cp/call.c:7050 0x55cd6c build_new_op_1 /home/uros/gcc-svn/trunk/gcc/cp/call.c:5355 0x55d217 build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*, tree_node*, tree_node**, int) /home/uros/gcc-svn/trunk/gcc/cp/call.c:5516 0x695922 cp_build_modify_expr(tree_node*, tree_code, tree_node*, int) /home/uros/gcc-svn/trunk/gcc/cp/typeck.c:7339 (Probably ICE on ivalid in this case).
(In reply to Uroš Bizjak from comment #0) > Created attachment 31403 [details] > Preprocessed source > > Attached testcase randomly fails to compile. Following valgrind error was > obtained on x86_64-pc-linux-gnu: > > $ valgrind /ssd/uros/gcc-build/gcc/cc1plus -g -O2 -std=gnu++0x > -fpreprocessed -quiet stdc++.ii > ==10906== Memcheck, a memory error detector > ==10906== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. > ==10906== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info > ==10906== Command: /ssd/uros/gcc-build/gcc/cc1plus -g -O2 -std=gnu++0x > -fpreprocessed -quiet stdc++.ii > ==10906== > ==10906== Invalid read of size 2 > ==10906== at 0x87F8FB: rtl_for_decl_init(tree_node*, tree_node*) > (dwarf2out.c:15183) (gdb) r Starting program: /ssd/uros/gcc-build/gcc/cc1plus -g -O2 -std=gnu++0x -fpreprocessed -quiet stdc++.ii Program received signal SIGSEGV, Segmentation fault. 0x000000000087f8fb in rtl_for_decl_init (init=init@entry=0x100139a078, type=type@entry=0x101) at /home/uros/gcc-svn/trunk/gcc/dwarf2out.c:15183 15183 if (TREE_CODE (init) == STRING_CST && TREE_CODE (type) == ARRAY_TYPE) (gdb) p init $1 = (tree) 0x100139a078 (gdb) p type $2 = (tree_node *) 0x101 (gdb)
(In reply to Uroš Bizjak from comment #2) > (gdb) p init > $1 = (tree) 0x100139a078 > (gdb) p type > $2 = (tree_node *) 0x101 > (gdb) FAIL: 17_intro/headers/c++200x/stdc++_multiple_inclusion.cc (test for excess errors) fails in the same way.
Isn't this related to PR58627 ? Try commenting out the ggc_free in there?
(In reply to Jakub Jelinek from comment #4) > Isn't this related to PR58627 ? > Try commenting out the ggc_free in there? Yes, both tests compile OK by removing mentioned gcc_free.
Dup. *** This bug has been marked as a duplicate of bug 58627 ***
These failures are still present on i686-pc-linux-gnu [1], rev 205955: Running target unix FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors) FAIL: 17_intro/headers/c++200x/stdc++_multiple_inclusion.cc (test for excess errors) [1] http://gcc.gnu.org/ml/gcc-testresults/2013-12/msg01213.html
On Linux/x86, I got spawn -ignore SIGHUP /export/gnu/import/git/gcc-test-ia32corei7/bld/./gcc/xg++ -shared-libgcc -B/export/gnu/import/git/gcc-test-ia32corei7/bld/./gcc -nostdinc++ -L/export/gnu/import/git/gcc-test-ia32corei7/bld/i686-linux/libstdc++-v3/src -L/export/gnu/import/git/gcc-test-ia32corei7/bld/i686-linux/libstdc++-v3/src/.libs -L/export/gnu/import/git/gcc-test-ia32corei7/bld/i686-linux/libstdc++-v3/libsupc++/.libs -B/usr/4.9.0/i686-linux/bin/ -B/usr/4.9.0/i686-linux/lib/ -isystem /usr/4.9.0/i686-linux/include -isystem /usr/4.9.0/i686-linux/sys-include -B/export/gnu/import/git/gcc-test-ia32corei7/bld/i686-linux/./libstdc++-v3/src/.libs -fdiagnostics-color=never -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/export/gnu/import/git/gcc-test-ia32corei7/bld/i686-linux/libstdc++-v3/include/i686-linux -I/export/gnu/import/git/gcc-test-ia32corei7/bld/i686-linux/libstdc++-v3/include -I/export/gnu/import/git/gcc-test-ia32corei7/src-trunk/libstdc++-v3/libsupc++ -I/export/gnu/import/git/gcc-test-ia32corei7/src-trunk/libstdc++-v3/include/backward -I/export/gnu/import/git/gcc-test-ia32corei7/src-trunk/libstdc++-v3/testsuite/util /export/gnu/import/git/gcc-test-ia32corei7/src-trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/stdc++.cc -std=gnu++0x -S -o stdc++.s^M In file included from /usr/include/features.h:375:0,^M from /usr/include/assert.h:36,^M from /export/gnu/import/git/gcc-test-ia32corei7/bld/i686-linux/libstdc++-v3/include/cassert:43,^M from /export/gnu/import/git/gcc-test-ia32corei7/src-trunk/libstdc++-v3/include/precompiled/stdc++.h:33:^M /usr/include/complex.h:112:1: internal compiler error: tree check: expected tree_vec, have error_mark in get_innermost_template_args, at cp/pt.c:581^M __END_DECLS^M ^^M 0x8938b68 tree_check_failed(tree_node const*, char const*, int, char const*, ...)^M ../../src-trunk/gcc/tree.c:9192^M 0x81a83b2 tree_check^M ../../src-trunk/gcc/tree.h:2707^M 0x81a83b2 get_innermost_template_args(tree_node*, int)^M ../../src-trunk/gcc/cp/pt.c:581^M 0x81aab84 get_template_innermost_arguments(tree_node const*)^M ../../src-trunk/gcc/cp/pt.c:3044^M 0x8155e7b get_template_innermost_arguments_folded^M ../../src-trunk/gcc/cp/cp-lang.c:213^M 0x847cf6d gen_generic_params_dies^M ../../src-trunk/gcc/dwarf2out.c:10546^M 0x8499dc8 gen_scheduled_generic_parms_dies^M ../../src-trunk/gcc/dwarf2out.c:20999^M 0x8499dc8 dwarf2out_finish^M ../../src-trunk/gcc/dwarf2out.c:23914^M Please submit a full bug report,^M with preprocessed source if appropriate.^M Please include the complete backtrace with any bug report.^M See <http://gcc.gnu.org/bugs.html> for instructions.^M
Note this must be PCH related, can't reproduce it without PCH even with --param ggc-min-expand=0 --param ggc-min-heapsize=0. Unfortunately I only reproduce it two i686 builds ago and don't remember the exact revision and what patches I had applied back then, so all I can see is that in the PCH file there is some TEMPLATE_DECL with it's decl_non_common.arguments set to error_mark_node when it ought to be TREE_LIST. So, if somebody can reproduce it right now with their current tree, it would be nice to debug where during PCH writing the bad value was stored and if it came from already by that time bogus TEMPLATE_DECL, or if it got broken during the PCH writing.
On Linux/x86-64, I got [hjl@gnu-34 ~]$ cat /tmp/x.cc #include <bits/stdc++.h> [hjl@gnu-34 ~]$ ... Starting program: /export/gnu/import/git/gcc-test-intel64corei7/bld/gcc/cc1plus -quiet -nostdinc++ -nostdinc++ -v -I /export/gnu/import/git/gcc-test-intel64corei7/bld/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I /export/gnu/import/git/gcc-test-intel64corei7/bld/x86_64-unknown-linux-gnu/libstdc++-v3/include -I /export/gnu/import/git/gcc-test-intel64corei7/src-trunk/libstdc++-v3/libsupc++ -I /export/gnu/import/git/gcc-test-intel64corei7/src-trunk/libstdc++-v3/include/backward -I /export/gnu/import/git/gcc-test-intel64corei7/src-trunk/libstdc++-v3/testsuite/util -iprefix /export/gnu/import/git/gcc-test-intel64corei7/bld/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.9.0/ -isystem /export/gnu/import/git/gcc-test-intel64corei7/bld/./gcc/include -isystem /export/gnu/import/git/gcc-test-intel64corei7/bld/./gcc/include-fixed -D_GNU_SOURCE -D _GLIBCXX_ASSERT -D _GNU_SOURCE -D _GNU_SOURCE -D LOCALEDIR=. -isystem /usr/4.9.0/x86_64-unknown-linux-gnu/include -isystem /usr/4.9.0/x86_64-unknown-linux-gnu/sys-include /tmp/x.cc -quiet -dumpbase x.cc -mtune=corei7 -march=corei7 -auxbase-strip /tmp/x.s -g -g -O2 -O2 -std=gnu++11 -version -fdiagnostics-color=never -fmessage-length=0 -ffunction-sections -fdata-sections -o /tmp/x.s GNU C++ (GCC) version 4.9.0 20131216 (experimental) [trunk revision 206016] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.9.0 20131216 (experimental) [trunk revision 206016], GMP version 5.1.1, MPFR version 3.1.1, MPC version 1.0.1 .. program received signal SIGSEGV, Segmentation fault. unlink_from_assembler_name_hash (node=0x100472aca0, with_clones=with_clones@entry=false) at ../../src-trunk/gcc/symtab.c:251 251 gcc_assert (*slot == node); Missing separate debuginfos, use: debuginfo-install glibc-2.17-20.0.fc19.x86_64 gmp-5.1.1-2.0.fc19.x86_64 libmpc-1.0.1-1.fc19.x86_64 mpfr-3.1.1-2.fc19.x86_64 zlib-1.2.7-10.fc19.x86_64 (gdb) p slot $1 = (void **) 0x0
It is PCH related. Stage1 and stage2 cc1plus can compile the same input. But stage3 cc1plus fails.
(In reply to H.J. Lu from comment #11) > It is PCH related. Stage1 and stage2 cc1plus can compile the same input. > But stage3 cc1plus fails. It is very sensitive PCH load address.
Also seen on x86_64-apple-darwin13 at r206072 (only once). Note that on x86_64-apple-darwin13 I see random PCH failures when I do the check with -j8, e.g.: WARNING: program timed out. FAIL: gcc.dg/pch/save-temps-1.c -O0 -g -I. -Dwith_PCH (test for excess errors) FAIL: gcc.dg/pch/save-temps-1.c -O0 -g assembly comparison FAIL: gcc.dg/pch/save-temps-1.c -O0 -I. -Dwith_PCH (internal compiler error) FAIL: gcc.dg/pch/save-temps-1.c -O0 -I. -Dwith_PCH (test for excess errors) FAIL: gcc.dg/pch/save-temps-1.c -O0 assembly comparison WARNING: program timed out. FAIL: g++.dg/pch/pch.C -O2 -g -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/pch.C -O2 -g assembly comparison WARNING: program timed out. FAIL: g++.dg/pch/pch.C -O2 -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/pch.C -O2 assembly comparison FAIL: g++.dg/pch/pch.C -g -I. -Dwith_PCH (internal compiler error) FAIL: g++.dg/pch/pch.C -g -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/pch.C -g assembly comparison Could it be related to this PR?
Doesn't seem to be related to make -jN, I can reproduce it every few iterations of: rm i686-pc-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch; /usr/src/gcc/obj825/./gcc/xgcc -shared-libgcc -B/usr/src/gcc/obj825/./gcc -nostdinc++ -L/usr/src/gcc/obj825/i686-pc-linux-gnu/libstdc++-v3/src -L/usr/src/gcc/obj825/i686-pc-linux-gnu/libstdc++-v3/src/.libs -L/usr/src/gcc/obj825/i686-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -x c++-header -nostdinc++ -g -O2 -D_GNU_SOURCE -I/usr/src/gcc/obj825/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu -I/usr/src/gcc/obj825/i686-pc-linux-gnu/libstdc++-v3/include -I/usr/src/gcc/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /usr/src/gcc/libstdc++-v3/include/precompiled/stdc++.h -o i686-pc-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch; /usr/src/gcc/obj825/./gcc/xg++ -shared-libgcc -B/usr/src/gcc/obj825/./gcc -nostdinc++ -L/usr/src/gcc/obj825/i686-pc-linux-gnu/libstdc++-v3/src -L/usr/src/gcc/obj825/i686-pc-linux-gnu/libstdc++-v3/src/.libs -L/usr/src/gcc/obj825/i686-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -B/usr/src/gcc/obj825/i686-pc-linux-gnu/./libstdc++-v3/src/.libs -fdiagnostics-color=never -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/usr/src/gcc/obj825/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu -I/usr/src/gcc/obj825/i686-pc-linux-gnu/libstdc++-v3/include -I/usr/src/gcc/libstdc++-v3/libsupc++ -I/usr/src/gcc/libstdc++-v3/include/backward -I/usr/src/gcc/libstdc++-v3/testsuite/util /usr/src/gcc/libstdc++-v3/testsuite/17_intro/headers/c++200x/stdc++.cc -std=gnu++0x -S -o stdc++.s So perhaps it is related to address space randomization during PCH writing or something similar. The *.gch file is different every time.
I've looked at dozens of the failures, except for one they were all about an expected TREE_VEC being written as 0s (i.e. ERROR_MARK) in the PCH file, the one exception was TREE_LIST instead of TREE_VEC. But it isn't always the same place that refers to the previously TREE_VEC, sometimes it is t->type_with_lang_specific->lang_specific->u.c.template_info->typed.type->decl_non_common->arguments which points to ERROR_MARK code instead of TREE_VEC, sometimes it is static tree get_template_argument_pack_elems_folded (const_tree t) { return fold_cplus_constants (get_template_argument_pack_elems (t)); } where get_template_argument_pack_elems returns TREE_TYPE of something and the TREE_TYPE is a TREE_VEC with 0s in the PCH file, etc. I've tried to disable ggc_free altogether (return early in the function), but that didn't fix this up. Using setarch x86_64 -R seems to reliably make the problem away, so whether we hit this or not depends on address space randomization of the process that saves the PCH file. So no idea how to debug this actually, perhaps only through instrumenting the kernel somehow (systemtap, something else)? I'd imagine if we recorded all the random values used during address space randomization of selected processes (cc1plus would be interesting for us), then run in a loop the PCH saving + PCH reading commands mentioned above until it fails and when it fails, looked into logs (systemtap, something else) what exact values the PCH saving cc1plus process used and then somehow arranged to replay those values reliably for all cc1plus invocations under some session, then supposedly it could be reliably reproduced.
The bad run has open("x86_64-unknown-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch", O_RDONLY|O_NOCTTY) = 5 fstat(5, {st_mode=S_IFREG|0644, st_size=78195440, ...}) = 0 read(5, "gpch+014l\272\361U\305\242H\350\25\237\343\320\316\t\376\323", 24) = 24 read(5, "\3\1\0\0\0\0\0\0\200\367x\0\0\0\0\0\340\0\0\0\0\0\0\0", 24) = 24 ... read(5, "r\5\0\20\0\0\0\340r\5\0\20\0\0\0\340r\5\0\20\0\0\0\340r\5\0\20\0\0\0\340"..., 4096) = 4096 read(5, "v\5\0\20\0\0\0p\236L\2\20\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 mmap(0x1000000000, 77393920, PROT_READ|PROT_WRITE, MAP_PRIVATE, 5, 0xc1000) = 0x1000000000 ... The good runs don't do mmap on PCH file.
Bad run has (gdb) bt #0 linux_gt_pch_use_address (base=0x1000000000, size=77393920, fd=9, offset=790528) at ../../src-trunk/gcc/config/host-linux.c:179 #1 0x000000000096556a in gt_pch_restore (f=f@entry=0x19985f0) at ../../src-trunk/gcc/ggc-common.c:703 #2 0x000000000078fe7c in c_common_read_pch (pfile=0x192eae0, name=0x19457d0 "x86_64-unknown-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch", fd=<optimized out>, orig_name=<optimized out>) at ../../src-trunk/gcc/c-family/c-pch.c:370 #3 0x00000000010a0de4 in should_stack_file (import=false, file=0x19456e0, pfile=<optimized out>) at ../../src-trunk/libcpp/files.c:787 #4 _cpp_stack_file (pfile=0x192eae0, file=0x19456e0, import=false) at ../../src-trunk/libcpp/files.c:872 #5 0x00000000010a1224 in _cpp_stack_include (pfile=0x192eae0, fname=0x194a120 "bits/stdc++.h", angle_brackets=1, type=IT_INCLUDE) at ../../src-trunk/libcpp/files.c:1009 #6 0x0000000001098fc6 in do_include_common (pfile=0x192eae0, type=IT_INCLUDE) at ../../src-trunk/libcpp/directives.c:793 #7 0x0000000001099b2e in _cpp_handle_directive (pfile=0x192eae0, indented=0) at ../../src-trunk/libcpp/directives.c:492 #8 0x00000000010a65cd in _cpp_lex_token (pfile=0x192eae0) at ../../src-trunk/libcpp/lex.c:2067 #9 0x00000000010aafe8 in cpp_get_token_1 (pfile=0x192eae0, location=0x49cf000, location@entry=0x7fffffffdd08) at ../../src-trunk/libcpp/macro.c:2362 #10 0x00000000010ab315 in cpp_get_token_with_location (pfile=<optimized out>, loc=loc@entry=0x7fffffffdd08) at ../../src-trunk/libcpp/macro.c:2544 #11 0x000000000078772a in c_lex_with_flags (value=value@entry=0x7fffffffdd10, loc=loc@entry=0x7fffffffdd08, cpp_flags=cpp_flags@entry=0x7fffffffdd02 "", lex_flags=lex_flags@entry=0) at ../../src-trunk/gcc/c-family/c-lex.c:302 ---Type <return> to continue, or q <return> to quit--- #12 0x000000000063a3a0 in cp_lexer_get_preprocessor_token (lexer=lexer@entry=0x0, token=token@entry=0x7fffffffdd00) at ../../src-trunk/gcc/cp/parser.c:759 #13 0x0000000000671416 in cp_parser_initial_pragma (first_token=0x7fffffffdd00) at ../../src-trunk/gcc/cp/parser.c:31048 #14 cp_lexer_new_main () at ../../src-trunk/gcc/cp/parser.c:629 #15 cp_parser_new () at ../../src-trunk/gcc/cp/parser.c:3386 #16 c_parse_file () at ../../src-trunk/gcc/cp/parser.c:31319 #17 0x000000000078f5e4 in c_common_parse_file () at ../../src-trunk/gcc/c-family/c-opts.c:1056 #18 0x0000000000b3ce26 in compile_file () at ../../src-trunk/gcc/toplev.c:547 #19 0x0000000000b3ede8 in do_compile () at ../../src-trunk/gcc/toplev.c:1887 #20 toplev_main (argc=29, argv=0x7fffffffde88) at ../../src-trunk/gcc/toplev.c:1963 #21 0x00000030a1a21b45 in __libc_start_main () from /lib64/libc.so.6 #22 0x000000000053d701 in _start () (gdb)
(In reply to H.J. Lu from comment #16) > The bad run has > > open("x86_64-unknown-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch", > O_RDONLY|O_NOCTTY) = 5 > fstat(5, {st_mode=S_IFREG|0644, st_size=78195440, ...}) = 0 > > The good runs don't do mmap on PCH file. It is because I used stage 2 cc1plus on PCH file generated by stage 3 cc1plus.
This also happens a number of times when running the boost testsuite. All ICEs turned out to be PCH related. For example (checking=release compiler): ... ==17975== Invalid read of size 8 ==17975== at 0x504951: lookup_page_table_entry(void const*) [clone .lto_priv.3354] (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975== by 0xAEEE89: ggc_set_mark(void const*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975== by 0x12438A1: gt_ggc_mx_lang_tree_node(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975== by 0x1246A78: gt_ggc_mx_tree_statement_list_node(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975== by 0x1244EAE: gt_ggc_mx_lang_tree_node(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975== by 0x1243A5A: gt_ggc_mx_lang_tree_node(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975== by 0x1243A5A: gt_ggc_mx_lang_tree_node(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975== by 0x1243A5A: gt_ggc_mx_lang_tree_node(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975== by 0x1244EE9: gt_ggc_mx_lang_tree_node(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975== by 0x1244F29: gt_ggc_mx_lang_tree_node(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975== by 0x1243D11: gt_ggc_mx_lang_tree_node(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975== by 0x1246353: gt_ggc_mx_lang_decl(void*) (in /usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.0/cc1plus) ==17975== Address 0x80 is not stack'd, malloc'd or (recently) free'd ==17975== In file included from ../boost/throw_exception.hpp:39:0, from ../boost/smart_ptr/shared_ptr.hpp:31, from ../boost/shared_ptr.hpp:17, from ../boost/test/tools/assertion_result.hpp:24, from ../boost/test/tools/old/impl.hpp:20, from ../boost/test/test_tools.hpp:32, from ../boost/math/tools/test.hpp:16, from ../libs/math/test/pch_light.hpp:10: ../boost/exception/exception.hpp: In member function ‘void boost::exception_detail::clone_impl<T>::rethrow() const [with T = boost::exception_detail::error_info_injector<std::logic_error>]’: ../boost/exception/exception.hpp:473:17: internal compiler error: Segmentation fault } ^ Please submit a full bug report, with preprocessed source if appropriate
FYI Mike's and Jakub's patch also fixes the boost testsuite issue.
Author: jakub Date: Tue Jan 7 07:47:57 2014 New Revision: 206383 URL: http://gcc.gnu.org/viewcvs?rev=206383&root=gcc&view=rev Log: PR pch/59436 * tree-core.h (struct tree_optimization_option): Change optabs type from unsigned char * to void *. * optabs.c (init_tree_optimization_optabs): Adjust TREE_OPTIMIZATION_OPTABS initialization. Modified: trunk/gcc/ChangeLog trunk/gcc/optabs.c trunk/gcc/tree-core.h
Author: jakub Date: Tue Jan 7 16:50:06 2014 New Revision: 206397 URL: http://gcc.gnu.org/viewcvs?rev=206397&root=gcc&view=rev Log: PR pch/59436 * tree.h (struct tree_optimization_option): Change optabs type from unsigned char * to void *. * optabs.c (init_tree_optimization_optabs): Adjust TREE_OPTIMIZATION_OPTABS initialization. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/optabs.c branches/gcc-4_8-branch/gcc/tree.h
Hopefully fixed.