On 1/4/24 18:02, Nathaniel Shead wrote:
On Thu, Jan 04, 2024 at 05:42:34PM -0500, Jason Merrill wrote:
On 1/4/24 17:24, Nathaniel Shead wrote:
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.
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.
Yes, that would be my expectation. What do other modules implementations
do?
Clang only emits ODR-used declarations (same as GCC currently).
MSVC emits all inline variables (whether exported or not) but no inline
functions.
Hmm, not a strong vote for my direction.
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 would guess avoid emitting if DECL_MODULE_IMPORT_P &&
DECL_MODULE_ATTACH_P.
Ah yup, that would make sense. I guess, thinking about it more, we
should then also ensure that all TREE_PUBLIC declarations are emitted in
the module interface even if not exported, since they may be needed in
implementation units?
That would also make sense to me; since we know the module interface
unit is compiled to an object file, everything vague linkage in it can
go there.
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).
Indeed.
I'll give implementing this a try then, if you think that would be
sensible. (Where by "this" I mean "emit all public declarations in
module interface files, whether used or not".)
I'd like to hear Nathan's thoughts on the matter first, since he's the
modules implementation designer.
Jason
