[Bug pch/90306] New: ICE when using precompiled headers with -MD and -fpch-deps
psmith at gnu dot org
gcc-bugzilla@gcc.gnu.org
Wed May 1 23:31:00 GMT 2019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90306
Bug ID: 90306
Summary: ICE when using precompiled headers with -MD and
-fpch-deps
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: pch
Assignee: unassigned at gcc dot gnu.org
Reporter: psmith at gnu dot org
Target Milestone: ---
I've seen this issue both with GCC 8.1.0 and the latest GCC 9.0.1 20190430
pre-release, on GNU/Linux x86_64 with binutils 2.30 and 2.32 (not that I
suppose that matters here).
Some info on the mailing list: https://gcc.gnu.org/ml/gcc/2019-04/msg00289.html
and into May: https://gcc.gnu.org/ml/gcc/2019-05/msg00001.html
I don't have a reproducible case since it doesn't happen every time for me.
But I can reproduce it locally on certain systems so I'm happy to participate
in some directed debugging. Here's what I've discovered so far:
IT WORKS FINE:
If I build my PCH file like this:
g++ <options> -o obj/foo_pch.h.gch -x c++-header foo_pch.h
And I build my source code like this:
g++ <options> -Winvalid-pch -iquote"obj" --include=foo_pch.h -o obj/foo.cpp.o
foo.cpp
I GET ICEs:
_Sometimes_ get ICE errors if I build as below on _some_ systems. It appears
possibly related to the speed of the system; it never fails on my local system
(which is very beefy) but often fails on our (older, less beefy) build servers.
First, when building the PCH file I add the -MD flag:
g++ <options> -MD -o obj/foo_pch.h.gch -x c++-header foo_pch.h
Second, when compiling my source code I add the -fpch-deps flag:
g++ <options> -fpch-deps -Winvalid-pch -iquote"obj" --include=foo_pch.h -o
obj/foo.cpp.o foo.cpp
Then I get ICE failures (this is from GCC 9.0.1-20190430):
<command-line>: internal compiler error: Segmentation fault
0x9d4fdb crash_signal
/work/src/cc/gcc-9.0.1-RC-20190430/gcc/toplev.c:326
0x12f6144 apply_vpath
/work/src/cc/gcc-9.0.1-RC-20190430/libcpp/mkdeps.c:127
0x12f648e deps_add_dep(deps*, char const*)
/work/src/cc/gcc-9.0.1-RC-20190430/libcpp/mkdeps.c:258
0x12f699c deps_restore(deps*, _IO_FILE*, char const*)
/work/src/cc/gcc-9.0.1-RC-20190430/libcpp/mkdeps.c:432
0x12f7cca cpp_read_state(cpp_reader*, char const*, _IO_FILE*,
save_macro_data*)
/work/src/cc/gcc-9.0.1-RC-20190430/libcpp/pch.c:859
0x59971c c_common_read_pch(cpp_reader*, char const*, int, char const*)
/work/src/cc/gcc-9.0.1-RC-20190430/gcc/c-family/c-pch.c:365
0x12e9d3c should_stack_file
/work/src/cc/gcc-9.0.1-RC-20190430/libcpp/files.c:814
0x12e9f33 _cpp_stack_file
/work/src/cc/gcc-9.0.1-RC-20190430/libcpp/files.c:900
0x12ea0ee _cpp_stack_include
/work/src/cc/gcc-9.0.1-RC-20190430/libcpp/files.c:1063
0x12ea5a6 cpp_push_include(cpp_reader*, char const*)
/work/src/cc/gcc-9.0.1-RC-20190430/libcpp/files.c:1498
0x597015 push_command_line_include
/work/src/cc/gcc-9.0.1-RC-20190430/gcc/c-family/c-opts.c:1502
0x59741b c_finish_options
/work/src/cc/gcc-9.0.1-RC-20190430/gcc/c-family/c-opts.c:1471
0x598dbc c_common_parse_file()
/work/src/cc/gcc-9.0.1-RC-20190430/gcc/c-family/c-opts.c:1150
Please submit a full bug report,
Debugging with GDB and follow-fork, I can see this backtrace:
(gdb) set follow-fork child
(gdb) run
Starting program:
/tools/x86_64-linux/cc/unknown/bin/x86_64-unknown-linux-gnu-g++ ... -fpch-deps
-Winvalid-pch -iquote/src/dir --include=foo_pch.h -o foo.cpp.o -c foo.cpp
[Attaching after process 310 vfork to child process 317]
[New inferior 2 (process 317)]
[Detaching vfork parent process 310 after child exec]
[Inferior 1 (process 310) detached]
process 317 is executing new program:
/tools/x86_64-linux/cc/unknown/libexec/gcc/x86_64-unknown-linux-gnu/9.0.1/cc1plus
Thread 2.1 "cc1plus" received signal SIGSEGV, Segmentation fault.
[Switching to process 317]
apply_vpath (d=d@entry=0x0,
t=t@entry=0x20a4530 "/src/foo_pch.h") at
/work/src/cc/gcc-9.0.1-RC-20190430/libcpp/mkdeps.c:127
127 /work/src/cc/gcc-9.0.1-RC-20190430/libcpp/mkdeps.c: No such file or
directory.
(gdb) bt
#0 apply_vpath (d=d@entry=0x0,
t=t@entry=0x20a4530 "/sec/foo_pch.h") at
/work/src/cc/gcc-9.0.1-RC-20190430/libcpp/mkdeps.c:127
#1 0x00000000012f648f in deps_add_dep (d=d@entry=0x0,
t=t@entry=0x20a4530 "/src/foo_pch.h") at
/work/src/cc/gcc-9.0.1-RC-20190430/libcpp/mkdeps.c:258
#2 0x00000000012f699d in deps_restore (deps=0x0, fd=fd@entry=0x20a1420,
self=self@entry=0x2039780 "/src/obj/foo_pch.h.gch")
at /work/src/cc/gcc-9.0.1-RC-20190430/libcpp/mkdeps.c:432
#3 0x00000000012f7ccb in cpp_read_state (r=r@entry=0x2027b70,
name=name@entry=0x2039780 "/src/obj/foo_pch.h.gch", f=f@entry=0x20a1420,
data=<optimized out>)
at /work/src/cc/gcc-9.0.1-RC-20190430/libcpp/pch.c:859
#4 0x000000000059971d in c_common_read_pch (pfile=0x2027b70,
name=0x2039780 "/src/obj/foo_pch.h.gch", fd=<optimized out>,
orig_name=<optimized out>)
at /work/src/cc/gcc-9.0.1-RC-20190430/gcc/c-family/c-pch.c:365
#5 0x00000000012e9d3d in should_stack_file (pfile=pfile@entry=0x2027b70,
file=file@entry=0x2039eb0, import=import@entry=false, loc=loc@entry=0)
at /work/src/cc/gcc-9.0.1-RC-20190430/libcpp/files.c:814
#6 0x00000000012e9f34 in _cpp_stack_file (pfile=pfile@entry=0x2027b70,
file=file@entry=0x2039eb0, import=import@entry=false, loc=loc@entry=0) at
/work/src/cc/gcc-9.0.1-RC-20190430/libcpp/files.c:900
#7 0x00000000012ea0ef in _cpp_stack_include (pfile=0x2027b70,
fname=<optimized out>, angle_brackets=angle_brackets@entry=0,
type=type@entry=IT_CMDLINE, loc=loc@entry=0) at
/work/src/cc/gcc-9.0.1-RC-20190430/libcpp/files.c:1063
#8 0x00000000012ea5a7 in cpp_push_include (pfile=<optimized out>,
fname=<optimized out>) at
/work/src/cc/gcc-9.0.1-RC-20190430/libcpp/files.c:1498
#9 0x0000000000597016 in push_command_line_include () at
/work/src/cc/gcc-9.0.1-RC-20190430/gcc/c-family/c-opts.c:1501
#10 0x000000000059741c in c_finish_options () at
/work/src/cc/gcc-9.0.1-RC-20190430/gcc/c-family/c-opts.c:1471
#11 0x0000000000598dbd in c_common_parse_file () at
/work/src/cc/gcc-9.0.1-RC-20190430/gcc/c-family/c-opts.c:1150
#12 0x00000000009d5211 in compile_file () at
/work/src/cc/gcc-9.0.1-RC-20190430/gcc/toplev.c:456
#13 0x00000000009d7150 in do_compile () at
/work/src/cc/gcc-9.0.1-RC-20190430/gcc/toplev.c:2205
#14 0x00000000009d7980 in toplev::main (this=this@entry=0x7fffffffd15e,
argc=<optimized out>, argc@entry=74, argv=<optimized out>,
argv@entry=0x7fffffffd258) at
/work/src/cc/gcc-9.0.1-RC-20190430/gcc/toplev.c:2340
#15 0x00000000012b770b in main (argc=74, argv=0x7fffffffd258) at
/work/src/cc/gcc-9.0.1-RC-20190430/gcc/main.c:39
As one can see, the "deps" option is null and we try to indirect through it:
static const char *
apply_vpath (struct deps *d, const char *t)
{
=> if (d->vpathv)
{
If I re-run this compilation command _without_ adding the -fpch-deps flag then
it does not ICE, even with the exact same PCH file. I can toggle this option
on/off and get/not get ICE.
Likewise if I don't add the -MD option to the creation of the PCH file I can't
seem to make this happen (although this could possibly just be a timing issue,
where -MD slows things down enough to make the real problem more likely).
And as I mentioned above, I can't reproduce this on all systems.
Based on available evidence, it appears that it is sometimes possible to write
out the PCH file with an empty set of "deps", and the code on the PCH
read/processing side doesn't expect that to happen. Even if apply_vpath()
didn't fail, other functions up the stack also indirect through deps without
checking (in fact no one checks).
However, apparently the only time the code tries to walk the deps is if you
provide the -fpch-deps flag, so this error would never be noticed unless that
option is given. Maybe it's not used so much.
Although I don't have a repro case I can make it happen here so I'm happy to do
some remote debugging if anyone would like to drive.
More information about the Gcc-bugs
mailing list