[PATCH] gcc 3.1 breaks wchan

[PATCH] gcc 3.1 breaks wchan

[Anton Blanchard]

Hi,

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.

Anton


--- linux-2.5/kernel/sched.c	Tue Apr 23 16:00:33 2002
+++ linux-2.5_work/kernel/sched.c	Thu Apr 25 11:38:45 2002
@@ -405,7 +405,8 @@
 }
 #endif
 
-static inline void context_switch(task_t *prev, task_t *next)
+/* This must end up inline or our wchan handling will break, so use extern */
+extern inline void context_switch(task_t *prev, task_t *next)
 {
 	struct mm_struct *mm = next->mm;
 	struct mm_struct *oldmm = prev->active_mm;

Re: [PATCH] gcc 3.1 breaks wchan

[Linus Torvalds]

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.

		Linus

Re: [PATCH] gcc 3.1 breaks wchan

[Anton Blanchard]

 
> 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.

Isnt that the correct behaviour for this function? We rely on that code
being inlined so if it doesnt get inlined we should fail to link. Im
not solving the problem with this patch, I'll leave that to the gcc
guys.

> 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.

Yes, Alan Modra just pointed me to __attribute__ ((always_inline)).

Anton

Re: [PATCH] gcc 3.1 breaks wchan

[Albert D. Cahalan]

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.

Re: [PATCH] gcc 3.1 breaks wchan

[Andreas Schwab]

"Albert D. Cahalan" <acahalan@cs.uml.edu> writes:

|> The compiler's
|> inability to inline something ought to be an error as well. Oh well.

-Winline -Werror

d&h, Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."