Re: [discuss] [2.6 patch] include/asm-x86_64 "extern inline" -> "static inline"

Adrian Bunk
2005-09-05T18:00:09Z

On Mon, Sep 05, 2005 at 10:52:47AM +0200, Michael Matz wrote:
> Hi,
>
> On Fri, 2 Sep 2005, Adrian Bunk wrote:
>
> > "extern inline" doesn't make much sense.
>
> It does. It's a GCC extension which says "never ever emit an out-of-line
> version of this function, not even if its address is taken", i.e. it's
> implicitely assumed, that if there is a need for such out-of-line variant,
> then it is provided by some other mean (for instance by defining it
> without inline markers in some .o file). Usually there won't be such need

So you agree with my statement that it doesn't make sense because there
are no out-of-line variants?

> as all instances are inlined, in which case the out-of-line version would
> be dead bloat, which you can't get rid of without this extension. And if
> some calls are not inlined then this extension serves as a poor mans
> check, because a link error will result.

In the kernel (with gcc >= 3.1), _every_ inline is forced to
always_inline resulting in gcc aborting with an error if it can't inline
the function.

Therefore any such out-of-line version if it existed would be dead
bloat.

> All in all, it does make sense, and no it's not the same as a "static
> inline", not even if forced always_inline.

It isn't the same, but "static inline" is the correct variant.

"extern inline __attribute__((always_inline))" (which is what
"extern inline" is expanded to) doesn't make sense.

> Ciao,
> Michael.

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed