------- 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
