https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119551
Bug ID: 119551
Summary: [modules] ICE when reading inline var referencing
TU-local entity
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nshead at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Blocks: 103524
Target Milestone: ---
Consider:
// a.cpp
export module M;
static int x = 0;
export inline int* y = &x;
// b.cpp
import M;
int main() {
return *y;
}
$ g++ -fmodules a.cpp b.cpp
cc1plus: internal compiler error: tree check: expected tree that contains
‘typed’ structure, have ‘tu_local_entity’ in canonicalize_constructor_val, at
gimple-fold.cc:248
0x3ccc6a3 internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:517
0x21bcf5d tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc/gcc/tree.cc:9288
0xec46f0 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3838
0x17e9b1a canonicalize_constructor_val(tree_node*, tree_node*)
../../gcc/gcc/gimple-fold.cc:248
0x15ad255 record_reference
../../gcc/gcc/cgraphbuild.cc:55
0x21c7ffe walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set<tree_node*, false, default_hash_traits<tree_node*> >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set<tree_node*, false, default_hash_traits<tree_node*> >*))
../../gcc/gcc/tree.cc:11602
0x15ae102 record_references_in_initializer(tree_node*, bool)
../../gcc/gcc/cgraphbuild.cc:398
0x226b776 varpool_node::analyze()
../../gcc/gcc/varpool.cc:537
0x15b26e3 analyze_functions
../../gcc/gcc/cgraphunit.cc:1319
0x15b5a8b symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.cc:2574
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
The standard says in https://eel.is/c++draft/basic.link#14.2 that we ignore
exposures in the initializers of variables or variable templates. However, for
inline variables we process the definitions as-needed in importers, causing
errors if we ever make use of this allowance.
(GCC14 didn't error, but the resultant executable immediately segfaults, which
is arguably even worse.)
There are probably two ways to approach this; either:
1. The ABI needs to be updated to indicate that the definitions of inline
variables in a named module interface should always be emitted in that TU, and
importers should then treat it as external and not attempt to instantiate the
definition themselves.
2. The C++ standard should be updated to make such exposures in inline
variables ill-formed. (This implies also that maybe class-scope 'static
constexpr' data members shouldn't be implicitly inline if attached to a named
module, like the treatment we have already for member functions? But this is
quite novel.)
I'm leaning towards implementing the second option, as this should result in
overall less churn. Jason, do you have any thoughts?
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
[Bug 103524] [meta-bug] modules issue
