Re: kernel-2.2.1-undefined references.

[Joe Buck <jbuck at Synopsys dot COM>]

Linus writes:

> If the programmer tells the compiler that the function should be inlined,
> the compiler had better comply with that.  At least until the compiler
> guys are certain that the compiler is smarter than the programmer, at
> which point I will concede just about anything.

Developers need to understand the limitations of the tools they use.
Under certain circumstances, the compiler will not be able to comply
with a user request to inline a function.  This is just life.
However ...

> It certainly doesn't have to be "extern inline", but I do believe that we
> need to have to have _some_ way of forcing inlining.

I believe that you already have what you need, in the sense that there
is a flag that, when set, will warn you if the compiler did not inline
a function that was flagged "inline".

`-Winline'
     Warn if a function can not be inlined, and either it was declared
     as inline, or else the `-finline-functions' option was given.

If you rely on inlines being performed for correct function you can use
that flag.

Reasons I know of that may cause inlining to fail include recursion
(except for some cases of tail recursion) or too much forward referencing
(if an inline function calls another inline function, it works best if
they appear from innermost to outermost in the source).  Excessively
complex functions also may not be inlinable, though gcc can handle some
fairly large ones.  So if you get the warning above, you can attempt to
clean things up so that the compiler succeeds in inlining the function.

While the C++ and draft C9X standards docs say that inline is just a
hint, this is generally not true with gcc, which normally attempts to
comply with user requests for inlining, unless there is a reason why it
cannot (as in the above list).