https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114630

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org

--- Comment #3 from Patrick Palka <ppalka at gcc dot gnu.org> ---
The following hack which forces instantiations induced from the GMF to actually
get instantiated within the GMF seems to fix the underlying issue:

diff --git a/gcc/cp/decl2.cc b/gcc/cp/decl2.cc
index 1339f210dde..dab98c02a63 100644
--- a/gcc/cp/decl2.cc
+++ b/gcc/cp/decl2.cc
@@ -2549,7 +2549,7 @@ decl_needed_p (tree decl)
 /* If necessary, write out the vtables for the dynamic class CTYPE.
    Returns true if any vtables were emitted.  */

-static bool
+bool
 maybe_emit_vtables (tree ctype, vec<tree> &consteval_vtables)
 {
   tree vtbl;
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 50d3ad35b61..7b91e2b6499 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -15173,6 +15173,23 @@ cp_parser_module_declaration (cp_parser *parser,
module_parse mp_state,
     }
   else
     {
+      if (mp_state == MP_GLOBAL)
+       /* ??? Make sure used specializations and vtables used within the
+          GMF are instantiated before starting the module purview.  */
+       for (int i = 0; i < 10; i++)
+         {
+           instantiate_pending_templates (0);
+           extern bool maybe_emit_vtables (tree, vec<tree> &);
+           tree t;
+           auto_vec<tree> consteval_vtables;
+           at_eof = 1;
+           for (int i = keyed_classes->length ();
+                keyed_classes->iterate (--i, &t);)
+             if (maybe_emit_vtables (t, consteval_vtables))
+               keyed_classes->unordered_remove (i);
+           at_eof = 0;
+         }
+
       module_state *mod = cp_parser_module_name (parser);
       if (mod && cp_lexer_peek_token (parser->lexer)->type == CPP_COLON)
        mod = cp_parser_module_partition (parser, mod);


But I don't really understand why..  What changes is that for 114630_b.C we now
instantiate the local types _M_do_parse<int>()::A/B locally at the end of the
GMF rather than at EOF, and later when doing the import we deduplicate their
imported definition rather than installing their imported definition.  And in
114630_c.C we no longer try to stream in the definition of _M_do_parse<int>()
twice, for some reason.

Maybe related, but I noticed that for

module;
template<class T> int f() { return 42; }
inline int x = f<int>();
export module foo;

without the above fix we instantiate f<int>() at EOF time and so
set_instantiating_module sets DECL_MODULE_PURVIEW_P for it, even though the
instantiation was induced from the GMF not the module purview.  With the above
fix we now instantiate f<int>() while still within the GMF and no longer set
DECL_MODULE_PURVIEW_P for f<int>().  I wonder to what extent
DECL_MODULE_PURVIEW_P matters on implicit instantiations?

Reply via email to