Increased build latency when multiple GCC processes share a precompiled header

Goal

Determine the root cause of the observable increase in compilation time when several GCC jobs simultaneously read the same precompiled header (.gch) file during a parallel build.

Constraints and uncertainty

GCC treats the .gch file as read‑only for consuming compilations and does not implement internal locking or a concurrency‑safe mode; the documentation leaves any required synchronization to the surrounding build system. It is unclear whether the added latency originates from repeated regeneration attempts when the header is considered out‑of‑date, from file‑system contention on the shared .gch, or from incoherent caches that force some processes to fall back to source parsing.

What conditions trigger GCC to attempt regeneration of a shared .gch file during concurrent builds? How does GCC handle read‑only access versus write attempts when multiple processes detect an out‑of‑date header? Are there any compiler flags or build‑system practices that can mitigate this serialization without relying on external locking?