aboutsummaryrefslogtreecommitdiff
path: root/lt~obsolete.m4
diff options
context:
space:
mode:
authorNathan Sidwell <nathan@acm.org>2020-12-08 09:05:32 -0800
committerNathan Sidwell <nathan@acm.org>2020-12-08 09:11:43 -0800
commitd04f3df82b737317c2759c314e28ee6243779252 (patch)
treee9a998b1d17a9b9cdb5b73ac46ad9105045b7ee7 /lt~obsolete.m4
parent005cff4e2ecbd5c4e2ef978fe4842fa3c8c79f47 (diff)
downloadgcc-d04f3df82b737317c2759c314e28ee6243779252.zip
gcc-d04f3df82b737317c2759c314e28ee6243779252.tar.gz
gcc-d04f3df82b737317c2759c314e28ee6243779252.tar.bz2
c++: Named module global initializers
C++ 20 modules adds some new rules about when the global initializers of imported modules run. They must run no later than before any initializers in the importer that appear after the import. To provide this, each named module emits an idempotent global initializer that calls the global initializer functions of its imports (these of course may call further import initializers). This is the machinery in our global-init emission to accomplish that, other than the actual emission of calls, which is in the module file. The naming of this global init is a new piece of the ABI. FWIW, the module's emitter does some optimization to avoid calling a direct import's initializer when it can determine thatr import is also indirect. gcc/cp/ * decl2.c (start_objects): Refactor and adjust for named module initializers. (finish_objects): Likewise. (generate_ctor_or_dtor_function): Likewise. * module.cc (module_initializer_kind) (module_add_import_initializers): Stubs.
Diffstat (limited to 'lt~obsolete.m4')
0 files changed, 0 insertions, 0 deletions