Re: GCC 3.4 and broken inlining.

[Adrian Bunk]

On Fri, Jul 09, 2004 at 06:51:46AM +0200, Andi Kleen wrote:
> Nigel Cunningham <ncunningham@xxxxxxxxxxxxx> 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?


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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/