Linus Torvalds writes:
> On Thu, 25 Apr 2002, Anton Blanchard wrote:
>> I noticed on a ppc64 kernel compiled with gcc 3.1 that context_switch
>> was left out of line. It ended up outside of the
>> scheduling_functions_start_here/end_here placeholders which breaks
>> wchan.
>>
>> This is one place where we require the code to be inline, so we
>> should use extern.
>
> ABSOLUTELY NOT!
>
> "extern inline" does not guarantee inlining. It only guarantees that _if_
> the code isn't inlined, it also won't be compiled as a static function.
>
> Complain to the gcc guys, they've made up some not-backwards-compatible
> thing called "always_inline" or something, apparently without any way to
> know whether it is supported or not.
This is why anything but INLINE or _INLINE (chosen in a Makefile
or header) is broken. Every compiler wants something different
these days. So, as needed, we get one of:
#define INLINE inline /* sanity! */
#define INLINE extern inline /* an oxymoron */
#define INLINE static inline /* another oxymoron */
#define INLINE __forceinline
#define INLINE __attribute__((always_inline))
#define INLINE inline_me_harder
#define INLINE inline_this_or_I_shove_it_up_your_gnu
BTW, I said this during the "extern inline" to "static inline" conversion.
IMHO "extern inline" and "static inline" are oxymorons and, were it
not for the silly C99 standard, ought to produce error messsages.
They make as much sense as "extern static" does. The compiler's
inability to inline something ought to be an error as well. Oh well.
-
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 Apr 30 2002 - 22:00:10 EST