Re: [patch 01/2] allow gcc4 to control inlining

[Ingo Molnar]

* Roland Dreier <rdreier@xxxxxxxxx> wrote:

>  > -#define inline			inline		__attribute__((always_inline))
>  > -#define __inline__		__inline__	__attribute__((always_inline))
>  > -#define __inline		__inline	__attribute__((always_inline))
> 
> Why not just delete these lines?  This:
> 
>  > +#define inline			inline
>  > +#define __inline__		__inline__
>  > +#define __inline		__inline
> 
> seems pointless to me.

indeed. I thought they were redefined to a default if not defined, but 
that's only the case for __always_inline. Updated patch below.

	Ingo

--------
Subject: allow gcc4 to control inlining

allow gcc4 compilers to decide what to inline and what not - instead
of the kernel forcing gcc to inline all the time.

Signed-off-by: Ingo Molnar <mingo@xxxxxxx>
Signed-off-by: Arjan van de Ven <arjan@xxxxxxxxxxxxx>
----

 include/linux/compiler-gcc4.h |    6 ++----
 1 files changed, 2 insertions(+), 4 deletions(-)

Index: linux/include/linux/compiler-gcc4.h
===================================================================
--- linux.orig/include/linux/compiler-gcc4.h
+++ linux/include/linux/compiler-gcc4.h
@@ -3,14 +3,12 @@
 /* These definitions are for GCC v4.x.  */
 #include <linux/compiler-gcc.h>
 
-#define inline			inline		__attribute__((always_inline))
-#define __inline__		__inline__	__attribute__((always_inline))
-#define __inline		__inline	__attribute__((always_inline))
 #define __deprecated		__attribute__((deprecated))
 #define __attribute_used__	__attribute__((__used__))
 #define __attribute_pure__	__attribute__((pure))
 #define __attribute_const__	__attribute__((__const__))
-#define  noinline		__attribute__((noinline))
+#define noinline		__attribute__((noinline))
+#define __always_inline		inline __attribute__((always_inline))
 #define __must_check 		__attribute__((warn_unused_result))
 #define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
 
-
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/