public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/99377] [modules] undefined std::string_view::empty() if referenced in inline exported function
Date: Wed, 10 Apr 2024 00:42:43 +0000	[thread overview]
Message-ID: <bug-99377-4-kdA7239Mia@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-99377-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #17 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Nathaniel Shead <nshead@gcc.gnu.org>:

https://gcc.gnu.org/g:77c0b5b23f91404004a9bf710981f6d615b63f57

commit r14-9881-g77c0b5b23f91404004a9bf710981f6d615b63f57
Author: Nathaniel Shead <nathanieloshead@gmail.com>
Date:   Thu Apr 4 23:16:08 2024 +1100

    c++: Track declarations imported from partitions [PR99377]

    The testcase in comment 15 of the linked PR is caused because the
    following assumption in depset::hash::make_dependency doesn't hold:

      if (DECL_LANG_SPECIFIC (not_tmpl)
          && DECL_MODULE_IMPORT_P (not_tmpl))
        {
          /* Store the module number and index in cluster/section,
             so we don't have to look them up again.  */
          unsigned index = import_entity_index (decl);
          module_state *from = import_entity_module (index);
          /* Remap will be zero for imports from partitions, which
             we want to treat as-if declared in this TU.  */
          if (from->remap)
            {
              dep->cluster = index - from->entity_lwm;
              dep->section = from->remap;
              dep->set_flag_bit<DB_IMPORTED_BIT> ();
            }
        }

    This is because at least for template specialisations, we first see the
    declaration in the header unit imported from the partition, and then the
    instantiation provided by the partition itself.  This means that the
    'import_entity_index' lookup doesn't report that the specialisation was
    declared in the partition and thus should be considered as-if it was
    part of the TU, and get emitted into the CMI.

    We always need to emit definitions from module partitions into the
    primary module interface's CMI, as unlike with other kinds of transitive
    imports the built CMIs for module partitions are not visible to
    importers.

    To fix this, this patch allows, as a special case for installing an
    entity from a partition, to overwrite the entity_map entry with the
    (later) index into the partition so that this assumption holds again.

    We only do this for the first time we override with a partition, so that
    entities are at least still reported as originating from the first
    imported partition that declares them (rather than the last); existing
    tests check for this and this seems to be a friendlier approach to go
    for, albeit slightly more expensive.

            PR c++/99377

    gcc/cp/ChangeLog:

            * module.cc (trees_in::install_entity): Overwrite entity map
            index if installing from a partition.

    gcc/testsuite/ChangeLog:

            * g++.dg/modules/pr99377-3_a.H: New test.
            * g++.dg/modules/pr99377-3_b.C: New test.
            * g++.dg/modules/pr99377-3_c.C: New test.
            * g++.dg/modules/pr99377-3_d.C: New test.

    Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>

  parent reply	other threads:[~2024-04-10  0:42 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-04  7:43 [Bug c++/99377] New: " boris at kolpackov dot net
2021-03-04 18:38 ` [Bug c++/99377] " nathan at gcc dot gnu.org
2021-03-05 17:11 ` nathan at gcc dot gnu.org
2021-03-05 19:55 ` cvs-commit at gcc dot gnu.org
2021-03-05 19:57 ` nathan at gcc dot gnu.org
2021-03-30 15:14 ` boris at kolpackov dot net
2021-11-29 22:05 ` johelegp at gmail dot com
2021-11-29 22:29 ` johelegp at gmail dot com
2021-12-20 18:35 ` johelegp at gmail dot com
2022-07-16 17:31 ` johelegp at gmail dot com
2022-07-16 17:32 ` johelegp at gmail dot com
2022-07-16 17:32 ` johelegp at gmail dot com
2022-07-16 17:32 ` johelegp at gmail dot com
2022-07-16 17:33 ` johelegp at gmail dot com
2022-07-17 16:21 ` johelegp at gmail dot com
2022-10-11 19:02 ` cvs-commit at gcc dot gnu.org
2022-10-12 15:13 ` ppalka at gcc dot gnu.org
2024-03-06 20:43 ` ppalka at gcc dot gnu.org
2024-04-10  0:42 ` cvs-commit at gcc dot gnu.org [this message]
2024-04-10  0:45 ` nshead at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-99377-4-kdA7239Mia@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).