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

[Adrian Bunk <bunk@stusta.de>]

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