Enabling C++20 modules in GCC breaks precompiled_header

[overlord624]

Passing the "-fmodules-ts" compiler option in GCC results in an implicitly appended .gch extension to the output of a precompiled_header directive. When this build step is then passed to an executable directive via the pch argument, the generated compiler instruction will not have the implicit extension added, which results in a "file not found" error.

Attached is a sample which triggers the issue, invoke as such:

CXX=g++-11 bfg9000 configure build --toolchain=toolchain.bfg
cd build
make

No error occurs if the toolchain argument is omitted or "-fmodules-ts" is removed from the toolchain definition file.
Note that modules were added in GCC 11 and this compiler option does not exist in earlier versions.

pch_module_sample.zip

[jimporter]

It seems to me that this is actually a bug in GCC (or they forgot to document something important):

From https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html:

A precompiled header file is searched for when #include is seen in the compilation. As it searches for the included file (see Search Path in The C Preprocessor) the compiler looks for a precompiled header in each directory just before it looks for the include file in that directory. The name searched for is the name specified in the #include with ‘.gch’ appended. If the precompiled header file cannot be used, it is ignored.

For instance, if you have #include "all.h", and you have all.h.gch in the same directory as all.h, then the precompiled header file is used if possible, and the original header is used otherwise.

...

This also works with -include.

In short, according to the GCC docs, you're supposed to refer to the file without the .gch.

My understanding of how compilers are implementing modules is that it's not particularly useful to combine the two features, but given that GCC lets you build a PCH with -fmodules-ts, it shouldn't complain when you try to use that PCH the way that the docs tell you.

[jimporter]

@overlord624, would you be able to make a further-reduced test case for this (not relying on bfg) and submit it to the GCC bug tracker? While I think I have enough information here to file the initial bug myself, I'm not sure I know enough about this situation to be able to answer any followup questions the GCC maintainers are likely to ask.

For bfg's purposes, my main question is, "How would GCC like users to explicitly include a PCH via the -include argument?"

[overlord624]

You are correct, this is indeed a compiler issue. It seems that specifying both '-x c++-header' and '-fmodules-ts' causes gcc to create a compiled header unit as outlined here:
https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/C_002b_002b-Modules.html#C_002b_002b-Modules

Header files may themselves be compiled to header units, which are a transitional ability aiming at faster compilation. The -fmodule-header option is used to enable this, and implies the -fmodules-ts option. These CMIs are named by the fully resolved underlying header file, and thus may be a complete pathname containing subdirectories. If the header file is found at an absolute pathname, the CMI location is still relative to a CMI root directory.

As header files often have no suffix, you commonly have to specify a -x option to tell the compiler the source is a header file. You may use -x c++-header, -x c++-user-header or -x c++-system-header. When used in conjunction with -fmodules-ts, these all imply an appropriate -fmodule-header option.

As a side effect, the -o option is ignored silently and no pch is emitted. I will submit this to the GCC tracker when my bugzilla account is activated. Feel free to close this issue.

[jimporter]

Great, thanks! If you post the GCC bug number here, I'll Cc myself to it and help answer any questions that come up (assuming I know the answer, of course).

I think it makes sense to leave this issue open though, if only so that anyone else who encounters this can easily find it (and so I can keep track of whether bfg needs a fix in the end).

[overlord624]

Posted on GCC bugtracker as bug number 101126.