public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Nathaniel Shead <nathanieloshead@gmail.com>
To: Jason Merrill <jason@redhat.com>
Cc: gcc-patches@gcc.gnu.org, Nathan Sidwell <nathan@acm.org>,
	Patrick Palka <ppalka@redhat.com>
Subject: Re: c++/modules: Emit definitions of ODR-used static members imported from modules [PR112899]
Date: Fri, 5 Jan 2024 09:24:47 +1100	[thread overview]
Message-ID: <65973034.170a0220.956b9.05dd@mx.google.com> (raw)
In-Reply-To: <8323d337-4bc3-4e65-9944-a2d579e66792@redhat.com>

On Thu, Jan 04, 2024 at 03:31:50PM -0500, Jason Merrill wrote:
> On 1/2/24 17:40, Nathaniel Shead wrote:
> > Static data members marked 'inline' should be emitted in TUs where they
> > are ODR-used.  We need to make sure that statics imported from modules
> > are correctly added to the 'pending_statics' map so that they get
> > emitted if needed, otherwise the attached testcase fails to link.
> 
> Hmm, this seems wrong to me; I'd think that static data members marked
> inline should be emitted in the module, and not in importers.
> 
> Jason
> 

That's what I'd initially thought too, but this is at least consistent
with non-class inlines (variables and functions), which similarly only
get emitted in TUs that they're ODR-used rather than always (and only)
being emitted within the module.

I guess an alternative would be to change it around so that all
exported definitions are marked as needed in the module interface file
(and emitted there), and then setting some flag so that they're never
emitted in importers. I'm not entirely sure what flag that would be
though, I still haven't quite wrapped my head what controls what with
regards to this, and I'm not convinced it wouldn't break template
instantiations.

I wonder if this might also be related to the issue Nathan noted with
regards to block-scope class methods, which I haven't completely worked
out how to solve yet otherwise (see
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638223.html).

Nathaniel

  reply	other threads:[~2024-01-04 22:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-02 22:40 Nathaniel Shead
2024-01-02 22:45 ` [PATCH] " Nathaniel Shead
2024-01-03 12:42   ` [PATCH v2] " Nathaniel Shead
2024-01-04 19:16     ` :Re: " Patrick Palka
2024-01-04 20:31 ` Jason Merrill
2024-01-04 22:24   ` Nathaniel Shead [this message]
2024-01-04 22:42     ` Jason Merrill
2024-01-04 23:02       ` Nathaniel Shead
2024-01-05  2:06         ` Jason Merrill
2024-01-06 22:30           ` Nathan Sidwell
2024-01-08  9:21             ` Iain Sandoe
2024-01-08 22:38               ` Jason Merrill
2024-01-19 18:57 ` Patrick Palka
2024-01-20 10:45   ` [PATCH v3] " Nathaniel Shead
2024-01-24 20:24     ` Jason Merrill
2024-01-26  2:28       ` [PATCH v4] " Nathaniel Shead
2024-01-26  3:35         ` Jason Merrill

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=65973034.170a0220.956b9.05dd@mx.google.com \
    --to=nathanieloshead@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    --cc=nathan@acm.org \
    --cc=ppalka@redhat.com \
    /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).