This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/39242] [4.4 Regression] Inconsistent reject / accept of code
- From: "rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 19 Feb 2009 16:54:54 -0000
- Subject: [Bug c++/39242] [4.4 Regression] Inconsistent reject / accept of code
- References: <bug-39242-10053@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #11 from rguenther at suse dot de 2009-02-19 16:54 -------
Subject: Re: [4.4 Regression] Inconsistent reject / accept
of code
On Thu, 19 Feb 2009, mark at codesourcery dot com wrote:
> ------- Comment #10 from mark at codesourcery dot com 2009-02-19 16:41 -------
> Subject: Re: [4.4 Regression] Inconsistent reject / accept
> of code
>
> rguenth at gcc dot gnu dot org wrote:
>
> > The ultimate question is of course if the standard allows (or even requires)
> > an error here.
>
> The (someone old) C++ WP I have is pretty clear:
>
> "An explicit instantiation declaration that names a class template
> specialization has no effect on the class template specialization
> itself (except for perhaps resulting in its implicit instantiation).
> Except for inline functions, other explicit
> instantiation declarations have the effect of suppressing the implicit
> instantiation of the entity to which they refer. [ Note:
> The intent is that an inline function that is the subject of an explicit
> instantiation declaration will still be implicitly instantiated
> when used so that the body can be considered for inlining, but that no
> out-of-line copy of the inline function
> would be generated in the translation unit. ???end note ]"
>
> Here, "inline function" is of course the C++ definition thereof, i.e.,
> functions declared "inline" or defined in the body of a class
> definition, rather than outside the class.
>
> What that means is that we *must not* implicitly instantiate things
> declared "extern template" unless they are DECL_DECLARED_INLINE_P. As a
> consequence, at -O3, we cannot implicitly instantiate non-inline "extern
> template" functions.
>
> So, I think first hunk in the patch is correct. It needs a comment,
> though, right above DECL_DECLARED_INLINE to point out that this is a
> restriction coming from the standard:
>
> /* An explicit instantiation declaration prohibits implicit
> instantiation of non-inline functions. With high levels of
> optimization, we would normally inline non-inline functions -- but we're
> not allowed to do that for "extern template" functions. Therefore, we
> check DECL_DECLARED_INLINE_P, rather than possibly_inlined_p. */
>
> OK with that change.
>
> I don't yet understand why the second hunk is required.
It is probably not, I just looked for all possibly_inlined_p
occurrences in instantiate_decl and tried to make sure behavior
does not depend on optimization level.
I'll split out the first part and test/submit it.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39242