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: -fobey-inline (was Re: gcc and inlining)


On Mar 14, 2003, Gabriel Dos Reis <gdr at integrable-solutions dot net> wrote:

> Lars Segerlund <lars dot segerlund at comsys dot se> writes:
> |   Are there any arguments against this other than ideological ?

> What is ideaological about attributre((always_inline))?

always_inline does have a very important use.  inline has never ever
meant `if you can't inline this, error out'.  IIRC, always_inline was
introduced to have a means to express this need.  This is actually
essential for code in say a dynamic loader's bootstrap code, in which
function calls cannot be expected to work, since it hasn't even
relocated itself yet.  I suppose some kernel code may have similar
needs as well.  Anyway, the point of always_inline is not about
inlining for performance, it's inlining for correctness.  If the
compiler turns out to be unable to inline the code, we want it to bail
out with an error, not just go ahead without inlining under the
assumption that it's funtionally-equivalent.  When you use
always_inline, it isn't.  Or at least it shouldn't be.  Whether the
implementation of always_inline has actually followed this suggestion,
and remained supporting this, I don't know.  But if it doesn't, I'd
call it a bug.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva at {redhat dot com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva at {lsd dot ic dot unicamp dot br, gnu.org}
Free Software Evangelist                Professional serial bug killer


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