public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Matt Austern <austern@apple.com>
To: Jason Merrill <jason@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [Darwin] Patch c++/15428
Date: Mon, 24 May 2004 12:57:00 -0000	[thread overview]
Message-ID: <EC66DBC2-AD44-11D8-BF14-000393B2ABA2@apple.com> (raw)
In-Reply-To: <xypzn82dd3u.fsf@miranda.boston.redhat.com>

On May 20, 2004, at 2:04 PM, Jason Merrill wrote:

> I still don't see why.  You explained above why this is necessary if
> there's a previous extern instantiation, but in that case we already do
> explicit instantiations on all targets.

I poked into this a bit more.  Oddly enough, what you said was right
under my original interpretation, for a reason neither of us noticed.
That is: the whole explicitly_instantiate_members stuff in
do_type_instantiation is unnecessary.  If you set it unconditionally
to 0, then, on all targets, what you'll get is still that an explicit
instantiation of a class template that has previously been marked
extern will result in all of its members getting explicitly
instantiated.  (But explicit instantiation of a class template that
hasn't been marked extern will result in implicit instantiation of
its members)

*However*: I think it's still probably a good idea to keep the
explicitly_instantiate_members stuff.  Without it, we're relying
on something that's a bit subtle and that I'm not convinced is
intentional.  It's there for another reason, and I think it gives
this behavior just by accident.  I don't want to count on it.

What's going on: the comments in do_type_instantiation say that
we're doing an implicit instantiation of the members.  So the
first thing we do is call mark_decl_instantiated(tmp, extern_p)
for each member.  Now take a look at mark_decl_instantiated.
If extern_p is true, it calls SET_DECL_EXPLICIT_INSTANTIATION.
(The comments say that it's there to prevent implicit
instantiation of an extern template.)  The explicit bit gets
set when we mark the template as extern.  The next time
through, when we do the real explicit instantiation, nobody has
cleared the extern bit, so we get explicit instantiations of
all the members.

Like I said, I think this is probably an accident.  I think the
extern bit was set just to prevent implicit instantiations, and
nobody thought about what it implied for the case of an extern
template that's later instantiated explicitly.

I'm inclined to keep the explicitly_instantiate_members code,
because it makes it clear what's going on.  But I could be
persuaded to get rid of it, and just put in a comment documenting
what's going on and asserting that it's intentional.

Thoughts?

			--Matt

  parent reply	other threads:[~2004-05-24  5:40 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-20  1:49 Matt Austern
2004-05-20 18:13 ` Jason Merrill
2004-05-20 20:28   ` Matt Austern
2004-05-20 21:02     ` Jason Merrill
2004-05-20 22:08       ` Matt Austern
2004-05-20 22:16         ` Jason Merrill
2004-05-22  8:54           ` Matt Austern
2004-05-22 12:25             ` Jason Merrill
2004-05-22 13:14               ` Matt Austern
2004-06-03 22:10             ` [Darwin] Patch c++/15428 (revised) Matt Austern
2004-06-03 22:43               ` Jason Merrill
2004-05-24 12:57           ` Matt Austern [this message]
2004-05-24 21:57             ` [Darwin] Patch c++/15428 Jason Merrill
2004-05-24 22:12               ` Matt Austern
2004-05-25  2:29                 ` Matt Austern
2004-05-25 21:43                   ` Jason Merrill
2004-05-25  2:40 Benjamin Kosnik

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=EC66DBC2-AD44-11D8-BF14-000393B2ABA2@apple.com \
    --to=austern@apple.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@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).