[lkml]   [2004]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: GCC 3.4 and broken inlining.
On Fri, Jul 09, 2004 at 06:51:46AM +0200, Andi Kleen wrote:
> Nigel Cunningham <> writes:
> I think a better solution would be to apply the appended patch
> And then just mark the function you know needs to be inlined
> as __always_inline__. I did this on x86-64 for some functions
> too that need to be always inlined (although using the attribute
> directly because all x86-64 compilers support it)
> The rationale is that the inlining algorithm in gcc 3.4+ is quite
> a lot better and actually eliminates some not-so-great inlining
> we had in the past and makes the kernel a bit smaller.

Making the kernel a bit smaller is a small improvement.

Runtime errors caused with gcc 3.4 are IMHO much worse than such a small
improvement or three dozen compile errors with gcc 3.4 .

The effect of your patch with gcc 3.4 would be nearly:
Ignore all old inlines and add something new that does what inline
did before.

Wouldn't it be a better solution if you would audit the existing inlines
in the kernel for abuse of inline and fix those instead?

> -Andi
> P.S.: compiler.h seems to be not "gcc 4.0 safe". Probably that needs
> to be fixed too.

My copy of compiler.h says:

<-- snip -->

#if __GNUC__ > 3
# include <linux/compiler-gcc+.h> /* catch-all for GCC 4, 5, etc. */

<-- snip -->

What exactly is wrong with this?



"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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:04    [W:0.095 / U:0.492 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site