On 5/1/24 07:11, Patrick Palka wrote:
On Wed, 1 May 2024, Nathaniel Shead wrote:Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- When calling instantiate_pending_templates at end of parsing, any new functions that are instantiated from this point have their module purview set based on the current value of module_kind. This is unideal, however, as the modules code will then treat these instantiations as reachable and cause large swathes of the GMF to be emitted into the module CMI, despite no code in the actual module purview referencing it. This patch fixes this by also remembering the value of module_kind when the instantiation was deferred, and restoring it when doing this deferred instantiation. That way newly instantiated declarations appropriately get a DECL_MODULE_PURVIEW_P appropriate for where the instantiation was required, meaning that GMF entities won't be counted as reachable unless referenced by an actually reachable entity. Note that purviewness and attachment etc. is generally only determined by the base template: this is purely for determining whether a specialisation was declared in the module purview and hence whether it should be streamed out. See the comment on 'set_instantiating_module'. PR c++/114630 PR c++/114795 gcc/cp/ChangeLog: * cp-tree.h (struct tinst_level): Add field for tracking module_kind. * pt.cc (push_tinst_level_loc): Cache module_kind in new_level. (reopen_tinst_level): Restore module_kind from level. (instantiate_pending_templates): Save and restore module_kind so it isn't affected by reopen_tinst_level.LGTM. Another approach is to instantiate all so-far deferred instantiations and vtables once we reach the start of the module purview, but your approach is much cleaner.
Hmm, I actually think I like the approach of instantiating at that point better, so that instantiations in the GMF can't depend on things in module purview.
And probably do the same again when switching to the private module fragment, when that's implemented.
Jason
