On Tue, 4 Mar 2008 08:32:48 +0100 Ingo Molnar <mingo@xxxxxxx> wrote: > > * Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > > urgh. This will cause whatever problem > > 4507a6a59cfc6997e532cd812a8bd244181e6205 fixed five years ago to > > resurface for incautious gcc-3.x users. > > hm, commit 4507a6a59cfc6997e532cd812a8bd244181e6205 does not exist: > > fatal: bad object 4507a6a59cfc6997e532cd812a8bd244181e6205 This was 2.5.x - you'll need to look in the historical-git tree. Here it is: : commit 4507a6a59cfc6997e532cd812a8bd244181e6205 : Author: akpm <akpm> : Date: Tue Mar 11 07:42:00 2003 +0000 : : [PATCH] work around gcc-3.x inlining bugs : : Force inlining even when gcc-3.x is too confused to do it for us. : : BKrev: 3e6d9348GA9aKzeN-bjzQzMMt85t8g : : diff --git a/include/linux/compiler.h b/include/linux/compiler.h : index e92f472..a28d0d5 100644 : --- a/include/linux/compiler.h : +++ b/include/linux/compiler.h : @@ -1,6 +1,12 @@ : #ifndef __LINUX_COMPILER_H : #define __LINUX_COMPILER_H : : +#if (__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1) : +#define inline __inline__ __attribute__((always_inline)) : +#define __inline__ __inline__ __attribute__((always_inline)) : +#define __inline __inline__ __attribute__((always_inline)) : +#endif : + : /* Somewhere in the middle of the GCC 2.96 development cycle, we implemented : a mechanism by which the user can annotate likely branch directions and : expect the blocks to be reordered appropriately. Define __builtin_expect : I was very bad about changelogging that one. I do remember there was a bit of to-and-fro before we decided to do it this way. Some googling would be needed. > but i suspect it must be something along the lines of the known problem > of really old gcc versions creating huge stackframes? iirc gcc was failing to inline functions which we'd marked `inline' and it was generating poorer code as a result. It might also have been generating an out-of-line copy for each compilation unit which called the inline (it would have to do this?) > Those pristine gcc > versions were practically unusable for distro kernels anyway (and were > patched by distros) - but i have no problem with restricting this > feature to gcc4x. gcc4x creates more compact -Os code too, so it's > recommended for smaller image sizes. yup. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
