Messages in this thread |  | | | Date | Fri, 9 Jul 2004 20:40:50 +0200 | | From | Adrian Bunk <> | | Subject | Re: GCC 3.4 and broken inlining. |
| |
On Fri, Jul 09, 2004 at 06:51:46AM +0200, Andi Kleen wrote: > Nigel Cunningham <ncunningham@linuxmail.org> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |