Increased build latency when multiple GCC processes share a precompiled header

Direct answer

The latency is caused by concurrent regeneration attempts on the shared .gch. GCC decides whether a precompiled header is usable by checking an embedded command-line hash and the header's modification time. When either check fails, GCC attempts to rebuild the .gch itself. GCC provides no internal locking or concurrency-safe mode for .gch files, so every parallel job that considers the file stale starts its own rebuild. The final rename step is serialized by the filesystem, which creates a bottleneck; jobs that lose the race fall back to parsing the original header, adding wasted work and latency.

What is confirmed vs. what is likely

Confirmed, well-established behavior: GCC uses a hash and timestamp comparison to validate a .gch, and it writes a temporary file before renaming it over the target. The likely explanation for your build is that multiple jobs are detecting an out-of-date .gch at the same time. Whether that is happening in your case depends on whether the header or relevant compile options change during the parallel phase; that is the part that needs verification in your own build.

Steps to remove the serialization

1. Generate the .gch once in a dedicated serial target before the parallel phase. For example:
   gcc -x c++-header -o common.h.gch common.h
2. Make the generated file read-only:
   chmod a-w common.h.gch
   GCC can still consume a read-only .gch. If the header later changes, your build system must repeat the serial regeneration step.
3. Add -fpch-preprocess to the consuming compilations. This flag tells GCC to treat an existing .gch as read-only and to fall back to source parsing instead of rewriting it. Pair it with -Winvalid-pch so you receive a warning when the PCH is not actually used.
4. Check your GCC version. -fpch-preprocess is generally available from GCC 4.7 onward; older releases may lack it. If you are on an older compiler, rely on the serial pre-step and read-only permissions alone.

Practical verification

Create a minimal header and its .gch, then run two parallel jobs that include the header. Use strace -f -e trace=openat,rename to observe whether both processes attempt to open the .gch for writing and rename over it. After applying the mitigation, the trace should show read-only opens and no competing rename attempts. Also confirm that -Winvalid-pch stays silent, meaning the PCH is still being used.

One missing diagnostic detail

Which GCC major version are you using? If it is older than 4.7, the -fpch-preprocess recommendation is unavailable and the build-system ordering plus file permissions become the only viable mitigation.