From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id 8278B383E828 for ; Tue, 26 May 2020 06:40:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8278B383E828 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sslab.ics.keio.ac.jp Authentication-Results: sourceware.org; spf=none smtp.mailfrom=takafumi.kubota1012@sslab.ics.keio.ac.jp Received: by mail-ej1-x630.google.com with SMTP id se13so22532854ejb.9 for ; Mon, 25 May 2020 23:40:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sslab.ics.keio.ac.jp; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XKurw2jWRlmROVB/vRW+XDwR/LnnN4/zHqX+x/W7BBw=; b=Jfv9K0hJIHTeSaTRDtOUw/1y/wVc2e2BVRa3OQ54/noiXsv6rZGlPb1wGTmbLaEu0+ xJ103p5Oyg2Fg8QfuJOGjbwBjo6jCNfrascQlrzYEvmr6mrcgt8aKEmFpQC9GalCFhMm jFZJxVDkvAKj9/u0FHqv4+BpxIgZKwA9jS7UQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XKurw2jWRlmROVB/vRW+XDwR/LnnN4/zHqX+x/W7BBw=; b=NQdWc89sVnf9suDqVAxSl11PHOUcKC6RwUfhRjr2fABH6BO6AI3m145jHqPbSoY+u4 T2myprkRJZyFtzOO1dI62M4R2/2AF3cgZIWNMQlZkSWaoQ9+v7hoowJFT6KAoEdAtW17 SOoJcZLLMwhIc/UAD3vaOlYL0I/TBSEGcNArlThpnw9pH9lPSOihxB0MJAdf8J1u+rMN w4DjY5K3TnlarSOZzYRINUu3NrXSJ6pTi2rZkaWja711Me4dCEkk7G5yJ2nCk1RkOfL5 mD384s92EvfUjRY4kG/DGNh6kLo2PVD79BtxphPDa9tNL58lJST1Ow8o/LFMevLJlYvP VCkQ== X-Gm-Message-State: AOAM533hzhu9pOmjMQJk1LlJB3/frLDkWkNGx+G3+VlTI4/MNIpqRZT8 G6QR6F3ZCzEoj5rhOn4Uq22/NCTA0NjQTHB8rE9pUQ== X-Google-Smtp-Source: ABdhPJzSL8s2D3qxYgJkeXhuRZIZOcUrWn1t9XE4RWeduOYTsbT6tXMF6ca8cVMYeqCH7Y6jUB540F0wDiuLiBmz5+s= X-Received: by 2002:a17:906:8556:: with SMTP id h22mr22739991ejy.535.1590475209464; Mon, 25 May 2020 23:40:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Takafumi Kubota Date: Tue, 26 May 2020 15:39:58 +0900 Message-ID: Subject: Re: Question about implicit template instantiation in C++ modules. To: Nathan Sidwell Cc: gcc-help@gcc.gnu.org X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 06:40:12 -0000 Thank you for the clarification! Takafumi 2020=E5=B9=B45=E6=9C=8825=E6=97=A5(=E6=9C=88) 23:35 Nathan Sidwell : > [redirected to gcc-help] > > On 5/25/20 12:27 AM, Kubota Takafumi wrote: > > Hi all, > > > > I am studying C++ modules and, especially, trying to understand how > implicitly > > instantiated template specializations are exported. > > Thanks for trying things out! > > > I encounter an example where GCC and Clang behave differently. > > > > For example: > > > > |/* mod1.cpp */ export module mod1; export { // function template > definition > > template T tmpl (T t) { return t; } // explicit > instantiation of > > "char tmpl" template char tmpl (char t); // implicit instantiatio= n > of "int > > tmpl" in exported section int f(int i) { return tmpl(i); } } // > implicit > > instantiation of "double tmpl" in not-exported section double > g(double > > d) { return tmpl(d); } /* main1.cpp */ import mod1; int main() { > tmpl('c'); // > > #1 tmpl(1); // #2 tmpl(1.0); // #3 return 0; } | > > > > Here, GCC reuses the explicitly instantiated specialization from mod1 a= t > #1. > > > > But, it implicitly re-instantiates at #2 and #3. > > > > On the other hand, Clang reuses all specializations from module mod1 fo= r > each point. > > Neither compiler is wrong. It is an implementation choice. All such > implicit > instantiations, regardless of origin are required to be ODR-same. I chos= e > not > to emit implicit instantiations, unless they are referenced by something > else in > the emitted graph. (it is not at all obvious which strategy is better) > > > So, I read the sections about modules and template instantiations in th= e > working > > draft of the technical specification [0][1][2]. > > > > However, as far as my understanding, there is no explanation about how > > implicitly instantiated template specializations are exported. > > Instantiations (explicit, implicit or partial) are not exported. Only > named > entities may be exported. (using the language's definition of 'export', > not the > closely related implementation concept of 'emitted into a Compiled Module > Interface'. > > > According to the comment of gcc/cp/module.c, there seem to be two desig= n > choices > > for exporting implicit specializations: re-instantiating them on-demand > (GCC's > > style) and streaming them (Clang's style) in modules. > > > > So my questions are: > > > > *Does how implicit specializations are exported depend on compiler > implementations?* > > Correct. > > > if not, > > > > *Does anyone know the expected behavior based on the technical > specification?* > > The std requires that a well formed program cannot tell the difference :) > > > > > Best Regards, > > > > Takafumi. > > > > [0] > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/n4849.pdf > > > > [1] http://eel.is/c++draft/ > > > > [2] > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1103r3.pdf > > > > > > -- > > Takafumi Kubota > > Ph.D. student at Keio University > > http://tk1012.github.io/ > > > -- > Nathan Sidwell > --=20 Takafumi Kubota Ph.D. student at Keio University http://tk1012.github.io/