http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45979
Summary: precompiled headers breakage on 2.6.36-rc Linux/ARM kernels Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@it.uu.se Recently I've started seeing massive pch test suite failures with gcc, both trunk and 4.4, on armv5tel-linux-gnueabi: FAIL: gcc.dg/pch/common-1.c -O2 -I. (test for excess errors) FAIL: gcc.dg/pch/common-1.c -O2 assembly comparison FAIL: gcc.dg/pch/common-1.c -O3 -fomit-frame-pointer -I. (test for excess errors) FAIL: gcc.dg/pch/common-1.c -O3 -fomit-frame-pointer assembly comparison FAIL: gcc.dg/pch/counter-1.c -O0 -g -I. (test for excess errors) FAIL: gcc.dg/pch/counter-1.c -O0 -g assembly comparison FAIL: gcc.dg/pch/counter-1.c -O3 -g -I. (test for excess errors) FAIL: gcc.dg/pch/counter-1.c -O3 -g assembly comparison FAIL: gcc.dg/pch/cpp-1.c -O0 -g -I. (test for excess errors) FAIL: gcc.dg/pch/cpp-1.c -O0 -g assembly comparison ...(many many more) These failures started after I did a major update of the Linux distro I run on my ARM boxes. I reverted a few likely suspects (glibc and the system gcc) to their earlier known-good versions, without effect, but in the end the failures were traced to the Linux kernel: - running linux-2.6.36-rc6 causes these PCH failures - reverting to linux-2.6.35 (similar .config) makes PCH tests pass again - pre-2.6.35 kernels are also known good The PCH test suite failures come from ICEs in cc1. I saved a core dump of which gdb says the following: Core was generated by `/home/mikpe/objdir/gcc/cc1 -quiet -I. -I. -iprefix /home/mikpe/temp/lib/gcc/arm'. Program terminated with signal 11, Segmentation fault. #0 linemap_lookup (set=0x40215000, line=73) at /home/mikpe/gcc-4.4-20100921/libcpp/line-map.c:284 284 if (line >= cached->start_location) Missing separate debuginfos, use: debuginfo-install glibc-2.10.2-1.bl8.armv5tel gmp-4.3.2-1.bl11.armv5tel mpfr-2.4.2-2.bl11.armv5tel (gdb) bt #0 linemap_lookup (set=0x40215000, line=73) at /home/mikpe/gcc-4.4-20100921/libcpp/line-map.c:284 #1 0x000cbed0 in diagnostic_report_current_module (context=0x790888) at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:236 #2 0x000cbffc in diagnostic_report_current_function (context=0xa4680042, diagnostic=0x49) at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:218 #3 0x000cc240 in default_diagnostic_starter (context=0xa4680042, diagnostic=0x49) at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:263 #4 0x000cb6c4 in diagnostic_report_diagnostic (context=0x790888, diagnostic=0xbe88b8e0) at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:403 #5 0x000cb940 in internal_error (gmsgid=0x6ecd70 "%s") at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:658 #6 0x00261cec in crash_signal (signo=-1098336032) at /home/mikpe/gcc-4.4-20100921/gcc/toplev.c:601 #7 <signal handler called> #8 linemap_lookup (set=0x40215000, line=73) at /home/mikpe/gcc-4.4-20100921/libcpp/line-map.c:284 #9 0x000cbed0 in diagnostic_report_current_module (context=0x790888) at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:236 #10 0x000cbffc in diagnostic_report_current_function (context=0xa4680042, diagnostic=0x49) at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:218 #11 0x000cc240 in default_diagnostic_starter (context=0xa4680042, diagnostic=0x49) at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:263 #12 0x000cb6c4 in diagnostic_report_diagnostic (context=0x790888, diagnostic=0xbe88bcf8) at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:403 #13 0x000cbab0 in fatal_error (gmsgid=0x5ca9f0 "had to relocate PCH") at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:640 #14 0x0015da80 in gt_pch_restore (f=0xbe88bcf8) at /home/mikpe/gcc-4.4-20100921/gcc/ggc-common.c:576 #15 0x00054608 in c_common_read_pch (pfile=0x134f170, name=0x1347a68 "./valid-6.h.gch", fd=<value optimized out>, orig_name=<value optimized out>) at /home/mikpe/gcc-4.4-20100921/gcc/c-pch.c:420 #16 0x00574a8c in should_stack_file (import=<value optimized out>, file=<value optimized out>, pfile=<value optimized out>) at /home/mikpe/gcc-4.4-20100921/libcpp/files.c:710 #17 _cpp_stack_file (import=<value optimized out>, file=<value optimized out>, pfile=<value optimized out>) at /home/mikpe/gcc-4.4-20100921/libcpp/files.c:795 #18 0x0056c168 in do_include_common (pfile=0x134f170, type=IT_INCLUDE) at /home/mikpe/gcc-4.4-20100921/libcpp/directives.c:784 #19 0x0056d028 in _cpp_handle_directive (pfile=0x134f170, indented=<value optimized out>) at /home/mikpe/gcc-4.4-20100921/libcpp/directives.c:488 #20 0x00579d60 in _cpp_lex_token (pfile=0x134f170) at /home/mikpe/gcc-4.4-20100921/libcpp/lex.c:1265 #21 0x0057d3bc in cpp_get_token (pfile=0x134f170) at /home/mikpe/gcc-4.4-20100921/libcpp/macro.c:1235 #22 0x0057d620 in cpp_get_token_with_location (pfile=0x5ca9f0, loc=0xa1000) at /home/mikpe/gcc-4.4-20100921/libcpp/macro.c:1347 #23 0x0000c750 in c_lex_with_flags (value=0xbe88bf20, loc=0xbe88bf24, cpp_flags=0x0, lex_flags=0) at /home/mikpe/gcc-4.4-20100921/gcc/c-lex.c:306 #24 0x00055114 in c_lex_one_token (parser=0xbe88bf1c, token=0xbe88bf1c) at /home/mikpe/gcc-4.4-20100921/gcc/c-parser.c:201 #25 0x000628c0 in c_parser_peek_token (parser=<value optimized out>, parser=<value optimized out>) at /home/mikpe/gcc-4.4-20100921/gcc/c-parser.c:310 #26 c_parse_file (parser=<value optimized out>, parser=<value optimized out>) at /home/mikpe/gcc-4.4-20100921/gcc/c-parser.c:8324 #27 0x00049e3c in c_common_parse_file (set_yydebug=<value optimized out>) at /home/mikpe/gcc-4.4-20100921/gcc/c-opts.c:1252 #28 0x00263e24 in compile_file () at /home/mikpe/gcc-4.4-20100921/gcc/toplev.c:970 #29 do_compile () at /home/mikpe/gcc-4.4-20100921/gcc/toplev.c:2197 ---Type <return> to continue, or q <return> to quit--- #30 toplev_main () at /home/mikpe/gcc-4.4-20100921/gcc/toplev.c:2229 #31 0x4018c3e0 in __libc_start_main () from /lib/libc.so.6 #32 0x0000aef0 in _start () Note #13. Apparently gcc "had to relocate PCH" (whatever that means) and tries to issue a diagnostic, which fails miserably in linemap_lookup. I also noticed many kernel messages about alignment traps in cc1, with PC values in linemap_lookup(). I'll try to bisect the 2.6.36-rc kernel changes to see what caused the PCH breakage. But even if this turns out to be a kernel bug (as opposed to the kernel just doing something different but valid), I don't think it's Ok for gcc to SEGV if it "had to relocate PCH".