public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Takafumi Kubota <takafumi.kubota1012@sslab.ics.keio.ac.jp>
To: Nathan Sidwell <nathan@acm.org>
Cc: gcc-help@gcc.gnu.org
Subject: Re: Question about implicit template instantiation in C++ modules.
Date: Tue, 26 May 2020 15:39:58 +0900	[thread overview]
Message-ID: <CA+wTq=XhzSv6OUhJ+vhuGf8cD+YDe-7FDE4T9CXxsqO1xPfmEA@mail.gmail.com> (raw)
In-Reply-To: <d26ec3bd-d168-f90f-e479-a1a0fd657a8f@acm.org>

Thank you for the clarification!

Takafumi

2020年5月25日(月) 23:35 Nathan Sidwell <nathan@acm.org>:

> [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 <typename T> T tmpl (T t) { return t; } // explicit
> instantiation of
> > "char tmpl<char>" template char tmpl (char t); // implicit instantiation
> of "int
> > tmpl<int>" in exported section int f(int i) { return tmpl(i); } } //
> implicit
> > instantiation of "double tmpl<double>" 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 at
> #1.
> >
> > But, it implicitly re-instantiates at #2 and #3.
> >
> > On the other hand, Clang reuses all specializations from module mod1 for
> 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 chose
> 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 the
> 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 design
> 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>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/n4849.pdf
> >
> > [1] <http://eel.is/c++draft/>http://eel.is/c++draft/
> >
> > [2]
> > <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1103r3.pdf>
> 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
>


-- 
Takafumi Kubota
Ph.D. student at Keio University
http://tk1012.github.io/

      reply	other threads:[~2020-05-26  6:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CA+wTq=X=+J==vmP7h-XGBPfdHEhNqBRbTQJrYU_MTeAyHXuZ_A@mail.gmail.com>
2020-05-25 14:35 ` Nathan Sidwell
2020-05-26  6:39   ` Takafumi Kubota [this message]

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='CA+wTq=XhzSv6OUhJ+vhuGf8cD+YDe-7FDE4T9CXxsqO1xPfmEA@mail.gmail.com' \
    --to=takafumi.kubota1012@sslab.ics.keio.ac.jp \
    --cc=gcc-help@gcc.gnu.org \
    --cc=nathan@acm.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).