On Wed, 4 Feb 2026 at 16:46, Jakub Jelinek <[email protected]> wrote:
>
> On Wed, Feb 04, 2026 at 11:35:50AM -0500, Patrick Palka wrote:
> > I didn't know PCH'd stdc++.h is so big! I'll continue using
> > --disable-libstdcxx-pch during development to avoid wearing down my
> > SSD (and avoid the slowdown of make having to rebuild the PCH after
> > every library header change).
> >
> > I wonder whether using PCH'd stdc++.h is still faster anymore given how
> > big the standard library is nowadays. Is the overhead of deserializing
> > the entire library AST, keeping it in memory, slowing down parts of the
> > front end that are >=linear in the size of the TU (including GC which is
> > frequent in checking mode) less than the overhead of not using PCH
> > and just parsing the subset of the library that's actually needed, for
> > our average libstdc++ testcase?
>
> I think for x86_64 PCH is not used anyway due to some CET related mismatch
> during testing but I could be wrong.
>
> If you don't GC, then just mapping it in should be quite fast and even
> if there is GC, while the first GC will take longer, it should kill
> everything not needed and get back to the normal size.
>
> Anyway, I wonder why we build the -O2ggnu++0x.gch files these days:
> -rw-r--r--. 1 jakub jakub 213581873 Feb 3 23:07
> ./x86_64-pc-linux-gnu/32/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/extc++.h.gch/O2g.gch
> -rw-r--r--. 1 jakub jakub 166490263 Feb 3 23:06
> ./x86_64-pc-linux-gnu/32/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/stdc++.h.gch/O2g.gch
> -rw-r--r--. 1 jakub jakub 101706811 Feb 3 23:06
> ./x86_64-pc-linux-gnu/32/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch
> -rw-r--r--. 1 jakub jakub 172619402 Feb 3 23:07
> ./x86_64-pc-linux-gnu/32/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/stdtr1c++.h.gch/O2g.gch
> -rw-r--r--. 1 jakub jakub 214381431 Feb 3 23:05
> ./x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/extc++.h.gch/O2g.gch
> -rw-r--r--. 1 jakub jakub 167179995 Feb 3 23:04
> ./x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/stdc++.h.gch/O2g.gch
> -rw-r--r--. 1 jakub jakub 102411920 Feb 3 23:04
> ./x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch
> -rw-r--r--. 1 jakub jakub 173411402 Feb 3 23:05
> ./x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/stdtr1c++.h.gch/O2g.gch
> That made sense when -std=gnu++98 has been the default, when -std=gnu++11
> has been the default no sense at all and even now, I think if we want to
> include something other than the default -std=gnu++20, it would be
> -std=gnu++17, not -std=gnu++0x, I hope most of C++ projects aren't stuck
> in C++11 days.
I must confess that I didn't even know we build those. I do my local
development with --disable-libstdcxx-pch and then run the full
testsuite on large servers where I don't notice those additional files
(and the time it takes to build them).
The 0x ones should go, and I doubt anybody cares about the stdtr1c++.h
header so the PCH for that could go too.
So maybe:
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -1104,15 +1104,15 @@ pch1_source =
${glibcxx_srcdir}/include/precompiled/stdc++.h
pch1_output_builddir = ${host_builddir}/stdc++.h.gch
pch1_output_anchor = ${host_builddir}/stdc++.h
pch1_output_installdir = ${host_installdir}/stdc++.h.gch
-pch1a_output = ${pch1_output_builddir}/O2ggnu++0x.gch
-pch1b_output = ${pch1_output_builddir}/O2g.gch
-pch1_output = ${pch1a_output} ${pch1b_output}
+pch1_output = ${pch1_output_builddir}/O2g.gch
+if GLIBCXX_BUILD_TR1_PCH
pch2_source = ${glibcxx_srcdir}/include/precompiled/stdtr1c++.h
pch2_output_builddir = ${host_builddir}/stdtr1c++.h.gch
pch2_output_anchor = ${host_builddir}/stdtr1c++.h
pch2_output_installdir = ${host_installdir}/stdtr1c++.h.gch
pch2_output = ${pch2_output_builddir}/O2g.gch
+endif
pch3_source = ${glibcxx_srcdir}/include/precompiled/extc++.h
pch3_output_builddir = ${host_builddir}/extc++.h.gch
And add an appropriate --enable-libstdcxx-tr1-pch option to enable
that. Or just remove it. The .h will still be installed, users who
want the PCH can compile it themselves.
