aboutsummaryrefslogtreecommitdiff
path: root/gcc/cp/mapper-client.h
diff options
context:
space:
mode:
authorPatrick Palka <ppalka@redhat.com>2022-10-11 15:02:01 -0400
committerPatrick Palka <ppalka@redhat.com>2022-10-11 15:02:01 -0400
commit2ceb4d531a303f3e70d8bb218c8759e6c0688f62 (patch)
tree18b790c3cc65b74989e6caa7a2757b23b8ba380b /gcc/cp/mapper-client.h
parent637e3668fdc17c4e226538fb14f9fab225433d01 (diff)
downloadgcc-2ceb4d531a303f3e70d8bb218c8759e6c0688f62.zip
gcc-2ceb4d531a303f3e70d8bb218c8759e6c0688f62.tar.gz
gcc-2ceb4d531a303f3e70d8bb218c8759e6c0688f62.tar.bz2
c++ modules: lazy loading from within template [PR99377]
Here when lazily loading the binding for f due to its first use from the template g, processing_template_decl is set which causes the call to note_vague_linkage_fn from module_state::read_cluster to have no effect, and thus we never push f onto deferred_fns and end up never emitting its definition despite needing it. The behavior of the lazy loading machinery shouldn't be sensitive to whether we're inside a template, so to that end this patch makes us clear processing_template_decl in the entrypoints lazy_load_binding and lazy_load_pendings. PR c++/99377 gcc/cp/ChangeLog: * module.cc (lazy_load_binding): Clear processing_template_decl. (lazy_load_pendings): Likewise. gcc/testsuite/ChangeLog: * g++.dg/modules/pr99377-2_a.C: New test. * g++.dg/modules/pr99377-2_b.C: New test.
Diffstat (limited to 'gcc/cp/mapper-client.h')
0 files changed, 0 insertions, 0 deletions