On 5/1/19 10:56 AM, Paul Smith wrote:
On Wed, 2019-05-01 at 09:35 -0400, Paul Smith wrote:
Unfortunately my GCC is heavily optimized and stripped so backtraces
are useless. I will generate a debuggable GCC and see if I can get
more info on the ICE.
I have created a GCC with debug enabled so I'll see what I find.
I was able to reproduce this ICE quite readily with my debuggable GCC
8.1.0. Here's the failure:
<command-line>: internal compiler error: Segmentation fault
0x9cae61 crash_signal
/work/src/cc/gcc-8.1.0/gcc/toplev.c:325
0x1293778 apply_vpath
/work/src/cc/gcc-8.1.0/libcpp/mkdeps.c:127
0x1293acc deps_add_dep(deps*, char const*)
/work/src/cc/gcc-8.1.0/libcpp/mkdeps.c:258
0x1293fe3 deps_restore(deps*, _IO_FILE*, char const*)
/work/src/cc/gcc-8.1.0/libcpp/mkdeps.c:432
0x129535b cpp_read_state(cpp_reader*, char const*, _IO_FILE*, save_macro_data*)
/work/src/cc/gcc-8.1.0/libcpp/pch.c:884
0x596d59 c_common_read_pch(cpp_reader*, char const*, int, char const*)
/work/src/cc/gcc-8.1.0/gcc/c-family/c-pch.c:373
0x12872fe should_stack_file
/work/src/cc/gcc-8.1.0/libcpp/files.c:814
0x12874f1 _cpp_stack_file
/work/src/cc/gcc-8.1.0/libcpp/files.c:900
0x12876a7 _cpp_stack_include
/work/src/cc/gcc-8.1.0/libcpp/files.c:1049
0x1287b22 cpp_push_include(cpp_reader*, char const*)
/work/src/cc/gcc-8.1.0/libcpp/files.c:1484
0x5943ec push_command_line_include
/work/src/cc/gcc-8.1.0/gcc/c-family/c-opts.c:1483
0x594615 c_finish_options
/work/src/cc/gcc-8.1.0/gcc/c-family/c-opts.c:1452
0x5963a2 c_common_parse_file()
/work/src/cc/gcc-8.1.0/gcc/c-family/c-opts.c:1126
Unsurprisingly the problem is that the "deps" data member in
cpp_reader* is null:
#0 apply_vpath (d=d@entry=0x0,
t=t@entry=0x2174860 "/src/foo_pch.h") at
/work/src/cc/gcc-8.1.0/libcpp/mkdeps.c:127
#1 0x0000000001293acd in deps_add_dep (d=d@entry=0x0,
t=t@entry=0x2174860 "/src/foo_pch.h") at
/work/src/cc/gcc-8.1.0/libcpp/mkdeps.c:258
#2 0x0000000001293fe4 in deps_restore (deps=0x0, fd=fd@entry=0x2171750,
self=self@entry=0x2106810 "/src/obj/foo_pch.h.gch")
at /work/src/cc/gcc-8.1.0/libcpp/mkdeps.c:432
#3 0x000000000129535c in cpp_read_state (r=r@entry=0x20f4d60,
name=name@entry=0x2106810 "/src/obj/foo_pch.h.gch", f=f@entry=0x2171750,
data=0x210bce0)
at /work/src/cc/gcc-8.1.0/libcpp/pch.c:884
I have no idea whether the problem is that it should never be possible
for "deps" to be null, or whether the problem is that we're not
checking for that possibility when we should be.
I'm building the current GCC 9.0.1 prerelease to see if I can reproduce
it there.
Once again removing -fpch-deps solves the problem. I can only assume
that without that flag we never bother to walk the deps data member at
all.
I've been playing with dep generation on the modules branch, and noticed
there did appear to be something funky going on with its interaction
with PCH. I didn't investigate, but have some patches that I'll be
merging in the not too distant future.
nathan
--
Nathan Sidwell
