This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] missing return warnings


Jan Hubicka wrote:

> One problem that I am concerned about is that C++ frontend is actually
> trying to avoid instantiating some stuff that it knows will not be
> needed if not inlined.  I would kill this logic, but I hope this is the
> case where the feature is not worth the maintenance cost.

We need to be careful about terms.  "Instantiating" means "substituting
actual arguments into a template definition to get an actual
definition".  There's also generating definitions for
implicitly-declared class member functions; that doesn't have a great
term in the standard, but we can call it "defining implicit functions".
 Which one of these situations are you concerned about?

I guess, in a way, it doesn't matter which one.  In both cases, the
standard says when you must do it.  So, we can't change that.

I suspect that the code that you're looking at may have just been a
front-end optimization.  For example, at least at one point, it made GCC
a lot slower to have very long instantiation chains: f needs g<int>,
g<int> needs h<int>, etc.  It was better to instantiate things one at a
time than to have a deep stack.  But, if h<int> was inline, then we
needed to make sure its body was available when g<int> was being
instantiated so that we could inline it.  Now, that's probably no longer
true.  We can probably always avoid the deep stack, and just let cgraph
handle it.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]