On 10/11/24 8:19 AM, Jakub Jelinek wrote:
On Wed, Oct 09, 2024 at 07:06:26PM -0400, Patrick Palka wrote:
On Wed, 9 Oct 2024, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu, will apply to trunk with the rest of the patch
series.
-- 8< --
At this point there doesn't seem to be much reason not to have modules
support enabled by default in C++20, and it's good get more test coverage to
find corner case bugs like some I fixed recently.
Not sure how much we care about PCH anymore, but won't this effectively
disable PCH in C++20 and later due to
/* C++ modules and PCH don't play together. */
if (flag_modules)
return 2;
in c_common_valid_pch?
Is it known why those 3 lines were added there?
Is it just somebody who uses modules doesn't need PCH, modules obsolete PCH,
or some code in module.cc lacking GTY(()) markups needed for PCH
save/restore, something else?
The intent is that C++20 module header units obsolete PCH; they serve
the same function and are more flexible (you can import multiple header
units).
Currently, compiling a header produces a PCH if modules are disabled, or
a header unit if modules are enabled.
There are certainly differences in how PCH and header units are found,
but the technique of compiling bits/stdc++.h and then -including it
should work the same.
...except that I suppose the libstdc++ layout of putting the .gch in the
same directory as the header won't work currently, both because the
modules compile ignores -o in favor of the build directory gcm.cache
(with the default module mapper) and because the compile also only looks
in gcm.cache by default. So I suppose it would be good to have more of
a transition plan there, even if it's just to build the header unit as
part of make check.
Jason
