Re: [patch] inlining: do not allow gcc below version 4 to optimizeinlining

[Adrian Bunk]

On Wed, Apr 30, 2008 at 12:15:31AM +0200, Ingo Molnar wrote:
> 
> fix the condition to match intention: always use the old inlining 
> behavior on all gcc versions below 4.
> 
> this should solve the UML build problem.

You reported this problem.

Does it fix the problem you reported or not?

> Signed-off-by: Ingo Molnar <mingo@xxxxxxx>
> ---
>  include/linux/compiler-gcc.h |    5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> Index: linux-x86.q/include/linux/compiler-gcc.h
> ===================================================================
> --- linux-x86.q.orig/include/linux/compiler-gcc.h
> +++ linux-x86.q/include/linux/compiler-gcc.h
> @@ -29,10 +29,11 @@
>    BUILD_BUG_ON_ZERO(__builtin_types_compatible_p(typeof(a), typeof(&a[0])))
>  
>  /*
> - * Force always-inline if the user requests it so via the .config:
> + * Force always-inline if the user requests it so via the .config,
> + * or if gcc is too old:
>   */
>  #if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) || \
> -    !defined(CONFIG_OPTIMIZE_INLINING) && (__GNUC__ >= 4)

One moment.

Let me try to understand what we currently have in the tree.

This *always* enables the so called "optimized inlining" for the older 
compilers we did *not* wanted to have this for.

Even with CONFIG_OPTIMIZE_INLINING=n .

How was this reviewed and tested?

> +    !defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4)
>  # define inline		inline		__attribute__((always_inline))
>  # define __inline__	__inline__	__attribute__((always_inline))
>  # define __inline	__inline	__attribute__((always_inline))

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/