ICE with precompiled headers (GCC 8.1)

[Nathan Sidwell]

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