https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114990
Bug ID: 114990
Summary: Compiler errors in <type_traits> compiling a
module-based app
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: admin at hexadigm dot com
Target Milestone: ---
Hi there,
This is a bit lengthy (code to reproduce reasonably short though) but intended
to provide sufficient detail. I'm getting numerous errors in the <type_traits>
(standard) header in V14.1 of GCC. It's a module-based app and the code below
is stripped down to the minimum required to demonstrate the issue (stripped
down so does nothing but should at least compile AFAIK - it doesn't). You can
run it in Compiler Explorer at https://godbolt.org/z/sh3c3TK8Y (same code
posted below but link itself relies on CMake - read on). See errors in top
executable window at latter link (targeting GCC 14.1) but compiles fine in
bottom executable window (targeting latest Clang). Also compiles in MSVC (not
shown at above link).
Note that if you simply comment out the #include <type_traits> statement seen
in "TypeTraits.h" OR the #include <iostream> statement seen in
"CompilerVersions.h" the errors disappear.
Unfortunately I have little experience in GCC (I specialize on MSFT platforms)
and don't have my own machine set up to test the situation (in GCC) so I depend
on CMake in the Compiler Explorer environment (not too experienced with CMake
either for that matter but very experienced in C++ - modules still relatively
new to most though).
Note that the "CMakeLists.txt" file at the above link is a bit elaborate
(didn't strip that particular file down) but it handles Clang and MSVC without
issue, and should handle GCC as well (designed to assuming no errors). It does
in fact when I compile a header-based version of the app (not module-based)
which I can control via switches passed to CMake. Presumably (hopefully) it's
not a CMake issue in the module version (or perhaps some issue with Compiler
Explorer) but I don't have access to a pure GCC environment to test things
further. Someone at your end will have to (sorry) but at this point it looks
like a GCC issue.
Here's the code (5 very short files):
###############################################################
$ cat CompilerVersions.h
#ifndef COMPILER_VERSIONS
#define COMPILER_VERSIONS
// #defined in "CompilerVersions.cppm" so only when that file is building
(and no other time)
#if !defined(STDEXT_BUILDING_MODULE_COMPILERVERSIONS)
import CompilerVersions;
#define DECLARE_MACROS_ONLY
#endif
#if !defined(DECLARE_MACROS_ONLY)
#include <iostream>
#endif
#endif
###############################################################
$ cat CompilerVersions.cppm
module;
#define STDEXT_BUILDING_MODULE_COMPILERVERSIONS
#include "CompilerVersions.h"
#undef STDEXT_BUILDING_MODULE_COMPILERVERSIONS
export module CompilerVersions;
###############################################################
$ cat TypeTraits.h
#ifndef TYPETRAITS
#define TYPETRAITS
#include "CompilerVersions.h"
// #defined in "TypeTraits.cppm" so only when that file is building (and no
other time)
#if !defined(STDEXT_BUILDING_MODULE_TYPETRAITS)
#include <type_traits>
import TypeTraits;
#endif
#endif
###############################################################
$ cat TypeTraits.cppm
module;
#define STDEXT_BUILDING_MODULE_TYPETRAITS
#include "TypeTraits.h"
#undef STDEXT_BUILDING_MODULE_TYPETRAITS
export module TypeTraits;
###############################################################
$ cat Main.cpp
#include "TypeTraits.h"
int main()
{
return 0;
}
I'm not sure what the command line is to compile the above code directly in GCC
(again, not a GCC developer - some should verify it) but presumably the
following or something similar (or all consolidated into one command if doable,
but would have to research it):
Compile the module interface units:
$ g++ -std=c++20 -fmodules-ts --module-interface -c CompilerVersions.cppm -o
CompilerVersions.o
$ g++ -std=c++20 -fmodules-ts --module-interface -c TypeTraits.cppm -o
TypeTraits.o
Compile the main program:
$ g++ -std=c++20 -fmodules-ts Main.cpp CompilerVersions.o TypeTraits.o -o Main
In Compiler Explorer itself (again, where I'm using CMake instead), many errors
result in <type_traits> but I'd expect the same or similar errors when running
the above GCC commands directly (TBD). Some of them are redefinition errors
which is suspicious given the nature of headers and modules in the same app. To
this end, and I have no idea if it actually has anything to do with the
problem, the "import CompilerVersions;" statement seen in "CompilerVersions.h"
does wind up in the global module fragment section of "TypeTraits.cppm" (where
headers normally go, not import statements), so I'm wondering if that has
something to do with it. If it is the cause, I'm not aware of any illegalities
(or undefined behaviour) in the standard on the use of "import" statements in
the global module fragment section, but it can happen indirectly such as in
cases like this. That is, should someone (as I have) decide to import a
dependency in a header instead of #including it in the traditional way
(especially during the transition from headers to modules), and the header then
winds up in the global module fragment section of a module, the "import"
statement for that dependency (indirectly) winds up there too of course. Could
this somehow be the cause here (just idle speculation only at this point)?
Thanks for your assistance.
