Seems that gcc looks for precompiled header in all include directories. Should we be doing this for all extensions?
My co-worker (who reported the bug) has tested the patch and it works in our build system, so the patch is functional.
I was about to suggest adding the same logic for Clang PCH/PTH, but I see that the .gch handling is considered a special case. So maybe it makes sense to keep it this way for GCC compat only.
Are the PCH paths generally assumed to be absolute?
Also, is a test possible? I still haven't got my head around the Clang test fx, but it feels like it should be possible to create a .gch in a temporary path, add the path to -I and verify that clang sees it when you attempt to force it in with -include.
The GCC docs here  say:
If not found there, it is searched for in the remainder of the #include "..." search chain as normal.
I can't tell if the quotes are significant and if they mean only -I is searched. I don't have a GCC environment currently to test with.
I found a FreeBSD machine and set up GCC. I had to adjust the repro case to use truss instead of strace, so I hope I didn't mess anything up.
I removed the rule generating the .gch file, so GCC would have to keep searching and it appears to be following the entire include search path, including system paths. Trace below:
So it seems that GCC *does* scan the entire header search path. Unfortunately, that information doesn't seem to be available to the driver (looks to be set up in CompilerInstance::createPreprocessor.
Should this logic for PCH/PTH scanning move out of the driver and into the frontend?
gcc also checks if the gch file is a directory and if so finds the first file with matching language / defines etc. It also uses gch files for #included files instead of just -included files (https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html). I thought clang intentionally did none of this so it doesn't have to stat all these directories.