https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101184
Bug ID: 101184
Summary: [modules] ICE and unexpected behavior when using
precisely 5 stl-memory includes.
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: 1lumin at protonmail dot com
Target Milestone: ---
The following five modules evoke a ICE when exporting module test_impl as
compiled with the commands below. The 5 file example below is the smallest I
could reduce it to, the standard memory include is used. Clang handles this
fine with both libc++ and libstdc++ memory includes.
gcc version 11.1.0
Target: x86_64-pc-linux-gnu
FILE: filler1.cc
/////////////////
module;
#include <memory>
export module filler1;
/////////////////
FILE: filler2.cc
/////////////////
module;
#include <memory>
export module filler2;
/////////////////
FILE: filler3.cc
/////////////////
module;
#include <memory>
export module filler3;
/////////////////
FILE: vec.cc
/////////////////
module;
#include <memory>
export module vec;
export template<typename T>
struct ivec{};
/////////////////
FILE: test_impl.cc
/////////////////
module;
#include <memory>
import filler1;
import filler2;
import filler3;
import vec;
export module test_impl;
ivec<float> g_vec2;
/////////////////
Commands to compile:
mkdir build
g++ -std=c++2a -fmodules-ts -c filler1.cc -o build/filler1.pcm
g++ -std=c++2a -fmodules-ts -c filler2.cc -o build/filler2.pcm
g++ -std=c++2a -fmodules-ts -c filler3.cc -o build/filler3.pcm
g++ -std=c++2a -fmodules-ts -c vec.cc -o build/vec.pcm
g++ -std=c++2a -fmodules-ts -c test_impl.cc -o build/test_impl.pcm
NOTES:
/////////////////
test_impl must be a module. If lines 1 and 10 are removed, it compiles fine.
Despite not exporting anything, filler 1, 2, and 3 must be included for the
error to occur. If any or all are removed, it compiles fine.
ivec must be a template. Even though the template argument is not used, if it
is of a non-template type, it compiles fine.
Memory as a the shared header is particular from what I have gathered, if
swapped with vector, array, functional, etc... it compiles fine.
g_vec2 must be defined in the module test_impl. The scope of g_vec2 within the
module does not seem to matter.
/////////////////
MISC:
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
test_impl.cc:10:8: internal compiler error: in write_location, at
cp/module.cc:15605
10 | export module test_impl;
| ^~~~~~
0x1797368 internal_error(char const*, ...)
???:0
0x67f8f9 fancy_abort(char const*, int, char const*)
???:0
0x7653b2 trees_out::core_vals(tree_node*)
???:0
0x765dd1 trees_out::tree_node_vals(tree_node*)
???:0
0x766d3a trees_out::decl_value(tree_node*, depset*)
???:0
0x761a9a trees_out::decl_node(tree_node*, walk_kind)
???:0
0x761e43 trees_out::tree_node(tree_node*)
???:0
0x764d30 module_state::write_cluster(elf_out*, depset**, unsigned int,
depset::hash&, unsigned int*, unsigned int*)
???:0
0x767ec9 module_state::write(elf_out*, cpp_reader*)
???:0
0x768d86 finish_module_processing(cpp_reader*)
???:0
0x713d1b c_parse_final_cleanups()
???:0
.ii of test_impl module is attached.
