[Bug c++/39242] [4.4 Regression] Inconsistent reject / accept of code

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.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