Fix powerpc ifunc-sel.h build for -Os

Fix powerpc ifunc-sel.h build for -Os

[Joseph Myers]

Compiling the testsuite for powerpc (multi-arch configurations) with
-Os with GCC 7 fails with:

In file included from ifuncmod1.c:7:0,
                 from ifuncdep1.c:3:
../sysdeps/powerpc/ifunc-sel.h: In function 'ifunc_sel':
../sysdeps/powerpc/ifunc-sel.h:12:3: error: asm operand 2 probably doesn't match constraints [-Werror]
   __asm__ ("mflr 12\n\t"
   ^~~~~~~
../sysdeps/powerpc/ifunc-sel.h:12:3: error: asm operand 3 probably doesn't match constraints [-Werror]
../sysdeps/powerpc/ifunc-sel.h:12:3: error: asm operand 4 probably doesn't match constraints [-Werror]
../sysdeps/powerpc/ifunc-sel.h:12:3: error: impossible constraint in 'asm'

The "i" constraints on function pointers require the function call to
be inlined so the compiler can see the constant function pointer
arguments passed to the asm.  This patch marks the relevant functions
as always_inline accordingly.

Tested that this fixes the -Os testsuite build for
powerpc-linux-gnu-power4, powerpc64-linux-gnu, powerpc64le-linux-gnu
with build-many-glibcs.py.

2018-02-27  Joseph Myers  <joseph@codesourcery.com>

	* sysdeps/powerpc/ifunc-sel.h (ifunc_sel): Make always_inline.
	(ifunc_one): Likewise.

diff --git a/sysdeps/powerpc/ifunc-sel.h b/sysdeps/powerpc/ifunc-sel.h
index bdb00bf..7112bed 100644
--- a/sysdeps/powerpc/ifunc-sel.h
+++ b/sysdeps/powerpc/ifunc-sel.h
@@ -4,7 +4,7 @@
 
 extern int global;
 
-static inline void *
+static inline __attribute__ ((always_inline)) void *
 inhibit_stack_protector
 ifunc_sel (int (*f1) (void), int (*f2) (void), int (*f3) (void))
 {
@@ -32,7 +32,7 @@ ifunc_sel (int (*f1) (void), int (*f2) (void), int (*f3) (void))
   return ret;
 }
 
-static inline void *
+static inline __attribute__ ((always_inline)) void *
 inhibit_stack_protector
 ifunc_one (int (*f1) (void))
 {

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Fix powerpc ifunc-sel.h build for -Os

[Joseph Myers]

On Tue, 27 Feb 2018, Sam Ravnborg wrote:

> It would be a little less verbose to use __always_inline from cdefs.h
> Note: I did not check if this is not feasible for some reasons

Some of the sources including ifunc-sel.h don't seem to include any system 
headers first (but I don't know if there's any particular reason they 
avoid system headers).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Fix powerpc ifunc-sel.h build for -Os

[Sam Ravnborg]

Hi Joseph.

On Tue, Feb 27, 2018 at 05:56:46PM +0000, Joseph Myers wrote:
> Compiling the testsuite for powerpc (multi-arch configurations) with
> -Os with GCC 7 fails with:
> 
> In file included from ifuncmod1.c:7:0,
>                  from ifuncdep1.c:3:
> ../sysdeps/powerpc/ifunc-sel.h: In function 'ifunc_sel':
> ../sysdeps/powerpc/ifunc-sel.h:12:3: error: asm operand 2 probably doesn't match constraints [-Werror]
>    __asm__ ("mflr 12\n\t"
>    ^~~~~~~
> ../sysdeps/powerpc/ifunc-sel.h:12:3: error: asm operand 3 probably doesn't match constraints [-Werror]
> ../sysdeps/powerpc/ifunc-sel.h:12:3: error: asm operand 4 probably doesn't match constraints [-Werror]
> ../sysdeps/powerpc/ifunc-sel.h:12:3: error: impossible constraint in 'asm'
> 
> The "i" constraints on function pointers require the function call to
> be inlined so the compiler can see the constant function pointer
> arguments passed to the asm.  This patch marks the relevant functions
> as always_inline accordingly.
> 
> Tested that this fixes the -Os testsuite build for
> powerpc-linux-gnu-power4, powerpc64-linux-gnu, powerpc64le-linux-gnu
> with build-many-glibcs.py.
> 
> 2018-02-27  Joseph Myers  <joseph@codesourcery.com>
> 
> 	* sysdeps/powerpc/ifunc-sel.h (ifunc_sel): Make always_inline.
> 	(ifunc_one): Likewise.
> 
> diff --git a/sysdeps/powerpc/ifunc-sel.h b/sysdeps/powerpc/ifunc-sel.h
> index bdb00bf..7112bed 100644
> --- a/sysdeps/powerpc/ifunc-sel.h
> +++ b/sysdeps/powerpc/ifunc-sel.h
> @@ -4,7 +4,7 @@
>  
>  extern int global;
>  
> -static inline void *
> +static inline __attribute__ ((always_inline)) void *
>  inhibit_stack_protector

It would be a little less verbose to use __always_inline from cdefs.h
Note: I did not check if this is not feasible for some reasons

>  ifunc_sel (int (*f1) (void), int (*f2) (void), int (*f3) (void))
>  {
> @@ -32,7 +32,7 @@ ifunc_sel (int (*f1) (void), int (*f2) (void), int (*f3) (void))
>    return ret;
>  }
>  
> -static inline void *
> +static inline __attribute__ ((always_inline)) void *
>  inhibit_stack_protector
Same goes here.

	Sam

Re: Fix powerpc ifunc-sel.h build for -Os

[Tulio Magno Quites Machado Filho]

Joseph Myers <joseph@codesourcery.com> writes:

> Compiling the testsuite for powerpc (multi-arch configurations) with
> -Os with GCC 7 fails with:
>
> In file included from ifuncmod1.c:7:0,
>                  from ifuncdep1.c:3:
> ../sysdeps/powerpc/ifunc-sel.h: In function 'ifunc_sel':
> ../sysdeps/powerpc/ifunc-sel.h:12:3: error: asm operand 2 probably doesn't match constraints [-Werror]
>    __asm__ ("mflr 12\n\t"
>    ^~~~~~~
> ../sysdeps/powerpc/ifunc-sel.h:12:3: error: asm operand 3 probably doesn't match constraints [-Werror]
> ../sysdeps/powerpc/ifunc-sel.h:12:3: error: asm operand 4 probably doesn't match constraints [-Werror]
> ../sysdeps/powerpc/ifunc-sel.h:12:3: error: impossible constraint in 'asm'
>
> The "i" constraints on function pointers require the function call to
> be inlined so the compiler can see the constant function pointer
> arguments passed to the asm.  This patch marks the relevant functions
> as always_inline accordingly.
>
> Tested that this fixes the -Os testsuite build for
> powerpc-linux-gnu-power4, powerpc64-linux-gnu, powerpc64le-linux-gnu
> with build-many-glibcs.py.

I can complete a build after this patch using GCC 7, but there are some
math tests failing on powerpc64le:
FAIL: math/test-float128-catan
FAIL: math/test-float64x-catan
FAIL: math/test-ifloat128-catan
FAIL: math/test-ifloat64x-catan
FAIL: math/test-ildouble-sin
FAIL: math/test-ldouble-finite-sin
FAIL: math/test-ldouble-sin
FAIL: math/test-tgmath

For the record: I tried with GCC 8 rev. 257983 too, but it seems to ignore the
diagnostic pragma.

Anyway, the patch looks good to me.

Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com>

-- 
Tulio Magno