In article <E15PpJg-0004D5-00@the-village.bc.nu>,
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> following is patch which was needed for compiling 2.4.7-ac1
>> on box equipped with 'gcc version 3.0.1 20010721 (Debian prerelease)'.
>> As I did not see such complaint yet - here it is.
>> If you think that gcc is too lazy on inlining (I think so...),
>> tell me and I'll complain to gcc team instead of here.
>
>Fix gcc. We use extern inline to say 'must be inlined' and that was the
>semantic it used to have. Some of our inlines will not work if the compiler
>uninlines them.
No, we had this fight with the gcc people a few years back, and they
have a very valid argument for the current semantics
- "static inline" means "we have to have this function, if you use it
but don't inline it, then make a static version of it in this
compilation unit"
- "extern inline" means "I actually _have_ an extern for this function,
but if you want to inline it, here's the inline-version"
The only problem with "static inline" was some _really_ old gcc versions
that did the wrong thing and made a static version of the function in
_every_ compilation unit, whether it was needed or not. Those versions of
gcc do not work on the kernel anyway these days, so..
I think the current gcc semantics are (a) more powerful than the old one
and (b) have been in effect long enough that it's not painful for Linux
to just switch over to them. In short, we might actually want to start
taking advantage of them, and even if we don't we should just convert
all current users of "extern inline" to "static inline".
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 21:00:29 EST