From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) by sourceware.org (Postfix) with ESMTPS id 351FB3858D35 for ; Sat, 6 Jan 2024 22:30:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 351FB3858D35 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=acm.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 351FB3858D35 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::82f ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704580235; cv=none; b=fT3Kgv7C0Z+H5eqBxWi4lOHX0D5G3ADZ5Z2p17ZD20DS0pWhZWVkyyge+mQcjd1I+9VNQi21DhKBaS5S9gluYW5x8PepwVsHoXMzV7pl1IOGFIneKDW9SBQLw4DOrQJkUFopLrBK8HP+VTg7UDbzquxCZsv+YlomhA0z5y+mpTw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704580235; c=relaxed/simple; bh=2ZC4vAa+qxw2Xs/Ti05O/vZI4rdWKhoMVd2KsYygcIk=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=q+uYV/9r9I99GnlratWyTUjtdH5Vy3VA8ui7cLMd7g+654WrNOf+yubrEsO++oqzHKADx82aM9ifni1HMVsFv+dnCMwUsfhUu0NfjqAHZge5wvEoMYNuk/u9EmiMa5kiOLgxf6Zp1Kg/q9XX/Ob48Qi7Abl9w28l1RtqBPpdzy0= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-qt1-x82f.google.com with SMTP id d75a77b69052e-427eabbaf25so6428111cf.0 for ; Sat, 06 Jan 2024 14:30:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704580232; x=1705185032; darn=gcc.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=E84XBim74u8OzkzQexSrU/7yhcDYHMLCI3RAcT6nCPA=; b=RdK9KmxHPx+fuj7nrKrJhTf5gmLteDJemB6cv+Ip8XGlvuh3atqCbWKb2kNYJQQKEC NV/49E0jkOC1Brk5zc7ndVKbixC4AtKYgvkVxyCCDXWJy4GEQ8jtdGIGk7w+mUv1x2UA oUJyOQSUQgJAJHVgba7fewG9VstHJq7r5diH3VV3bjFyrsz7T9stLks3hypdFMZppeAa PFzWyDoBoE+wXYr4g21U9mtQ2juSzEH97g4/43wQjbUy0vYTLRS40umNfhk55WddxiZO zj+333Ganwn8obekismx4Dwefc3cjAwup3g0SUWLxX7AjgFjBtLwz2ItWUn/K7nE4srr ColA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704580232; x=1705185032; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=E84XBim74u8OzkzQexSrU/7yhcDYHMLCI3RAcT6nCPA=; b=RWZKxeZnNGHGWMFPxvfvkSajAQ+rJQv3SKS343lpYhczyEa7iBmE9m8nH5ohsjdgo3 ckNGKmnhIbLzC01Nia7kGdR2yqi4Qpjnwt7hE/jRbRysHCJ/YH34bG7w7LUn7IORrVU5 RdeWvTYBhB8Evafd7dLOhxMmEXIapwvIBOq/VEa0/0zajbD91FNpfiGspNqeLzUNGy/b +MFHOVknBw3AJF9f6FHKyRGystEVzgwAFraRQJ/UeG8wiAhFzfnmsTRMtJETzm8wfoTl rhl8KXbkM7xEaQ8o3kZ5piPREgCY1FnP1xHogBIDs5Gs8yI5T+9rl9MVQCxT3RcgXtN2 OCcg== X-Gm-Message-State: AOJu0YwNRhqAsHG2YGuK5/wypbbtjirik9hMUTzRSwQ5UuyUgm4bfC2P 7hI4xN7y+AT1uwnd5GOZfto= X-Google-Smtp-Source: AGHT+IFlr2usWL3s3xTbLqdoVYGnniP310WXRDXK9V9+KjufBnuPRCadNwO7gJ6L/Jj8JwbIdpkShA== X-Received: by 2002:ac8:7656:0:b0:429:71f9:25b1 with SMTP id i22-20020ac87656000000b0042971f925b1mr5253709qtr.1.1704580232359; Sat, 06 Jan 2024 14:30:32 -0800 (PST) Received: from ?IPV6:2600:4040:5b0e:b500:15a3:ac43:deab:f0a7? ([2600:4040:5b0e:b500:15a3:ac43:deab:f0a7]) by smtp.googlemail.com with ESMTPSA id cb14-20020a05622a1f8e00b0042837900d7bsm2013863qtb.11.2024.01.06.14.30.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 Jan 2024 14:30:31 -0800 (PST) Sender: Nathan Sidwell Message-ID: <47a431b5-1069-4490-912d-c4f2448e8a14@acm.org> Date: Sat, 6 Jan 2024 17:30:25 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: c++/modules: Emit definitions of ODR-used static members imported from modules [PR112899] Content-Language: en-US To: Jason Merrill , Nathaniel Shead Cc: gcc-patches@gcc.gnu.org, Patrick Palka , Iain Sandoe References: <659490fd.170a0220.1ce2e.503a@mx.google.com> <8323d337-4bc3-4e65-9944-a2d579e66792@redhat.com> <65973034.170a0220.956b9.05dd@mx.google.com> <67820559-178e-421f-8cde-7c2072c2e8eb@redhat.com> <65973909.170a0220.51811.06dc@mx.google.com> <6a2ceb65-3c71-4540-87ec-4c7a24a9169b@redhat.com> From: Nathan Sidwell In-Reply-To: <6a2ceb65-3c71-4540-87ec-4c7a24a9169b@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3032.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Richard Smith & I discussed whether we should use the module interface's capability of giving vague linkage entities a strong location. I didn't want to go messing with that, 'cos it was changing yet more stuff. But, perhaps we should revisit that? Any keyless polymorphic class in module purview gets its vtables etc emitted in the module's object file? Likewise these kinds of entities. cc'ing Iain, who probably knows more about Clang's state here. nathan On 1/4/24 21:06, Jason Merrill wrote: > 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 > -- Nathan Sidwell