On Tue, 2019-04-30 at 09:43 -0400, Paul Smith wrote:
> Here's the thing: I added the "-MD -MF foo.d" options to the PCH file
> compile (I wanted to get a manifest of which files were included in the
> PCH file). Without those options I cannot reproduce this at all (in a
> number of tries). With those options it happens most of the time on
> some systems (but again, never on my local system).
I have made more discoveries.
In the compiler invocation that is ICEing, if I remove the -fpch-deps
option then it no longer ICEs (with the same PCH file that ICEd
before!) I can remove/add that option to my .cpp compile line, and it
ICEs with it and works without it, no other changes.
But again, it works fine on my system always. So there's _sometimes_
something odd inside the PCH file which is triggered by the source file
compilation adding -fpch-deps.
FWIW, here's the compile line I use to generate the PCH:
g++ ...opts... -MD -MF dir/foo.h.d -o dir/foo.h.gch -x c++-header foo.h
And here's the compile line I use to compile source code:
g++ ...opts... -fpch-deps -fpch-preprocess -Winvalid-pch \
-iquote"dir" --include=foo.h
Adding/removing -fpch-preprocess doesn't seem to matter. It's only the
-fpch-deps option during the compile, combined with the -MD/-MF options
when creating the PCH file, that seems to trigger the ICE.
> 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.
