[2/3] powerpc: Add redirection for finitef128, isinf128, and isnanf128

  On powerpc64le, compiler support for float128 is not enabled by default
on gcc.  To enable it, the flag -mfloat128 must be passed as a command
line option to the compiler.  This means that only the few files that
actively have -mfloat128 passed as an argument get compiler support for
float128, whereas all other files don't.

When -mfloat128 becomes enabled by default on powerpc [1], all the files
that do not currently have compiler support for float128 enabled during
their compilation, will start to have it.  This will lead to build
errors in some of these files.

This patch defines __finitef128 as __redirect___finitef128 in
sysdeps/powerpc/powerpc64/fpu/multiarch/s_finite.c, similarly to what's
done for the float, double, and long double versions of these functions,
to get rid of the build error.  Likewise for isinff128 and isnanf128.

[1] https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01028.html

Tested for powerpc64le with patched [1] and unpatched gcc.

	* sysdeps/powerpc/powerpc64/fpu/multiarch/s_finite.c
	(__finitef128): Define to __redirect___finitef128.
	* sysdeps/powerpc/powerpc64/fpu/multiarch/s_isinf.c
	(__isinff128): Define to __redirect___isinff128.
	* sysdeps/powerpc/powerpc64/fpu/multiarch/s_isnan.c
	(__isnanf128): Define to __redirect___isnanf128.
---
 sysdeps/powerpc/powerpc64/fpu/multiarch/s_finite.c | 1 +
 sysdeps/powerpc/powerpc64/fpu/multiarch/s_isinf.c  | 1 +
 sysdeps/powerpc/powerpc64/fpu/multiarch/s_isnan.c  | 1 +
 3 files changed, 3 insertions(+)
  

On Thu, 7 Sep 2017, Gabriel F. T. Gomes wrote:

> This patch defines __finitef128 as __redirect___finitef128 in
> sysdeps/powerpc/powerpc64/fpu/multiarch/s_finite.c, similarly to what's
> done for the float, double, and long double versions of these functions,
> to get rid of the build error.  Likewise for isinff128 and isnanf128.

What is the build error?  Why should s_finite.c need to redirect 
__finitef128, or to redirect __finitef or __finitel for that matter?  
s_finitef.c manages to redirect only __finitef, not any of the other 
versions, after all.
  

On Thu, 7 Sep 2017 14:39:42 +0000
Joseph Myers <joseph@codesourcery.com> wrote:

>On Thu, 7 Sep 2017, Gabriel F. T. Gomes wrote:
>
>> This patch defines __finitef128 as __redirect___finitef128 in
>> sysdeps/powerpc/powerpc64/fpu/multiarch/s_finite.c, similarly to what's
>> done for the float, double, and long double versions of these functions,
>> to get rid of the build error.  Likewise for isinff128 and isnanf128.  
>
>What is the build error?  Why should s_finite.c need to redirect 
>__finitef128, or to redirect __finitef or __finitel for that matter?  
>s_finitef.c manages to redirect only __finitef, not any of the other 
>versions, after all.

I'm sorry for not making this clear in the patch itself.  I'll try to
explain what was my rationale and if that sounds OK, I'll add that to the
commit message and comments.

This is the build error:

In file included from <command-line>:0:0:
../include/math.h:29:15: error: ‘__finitef128’ undeclared here (not in a function); did you mean ‘__rintf128’?
 hidden_proto (__finitef128)
               ^~~~~~~~~~~~
./../include/libc-symbols.h:518:27: note: in definition of macro ‘__hidden_proto’
   extern thread __typeof (name) name __hidden_proto_hiddenattr (attrs);
                           ^~~~
../include/math.h:29:1: note: in expansion of macro ‘hidden_proto’
 hidden_proto (__finitef128)
 ^~~~~~~~~~~~

The output of the preprocessor has the following lines (snippets):

# 21 "../math/bits/mathcalls-helper-functions.h"
[...]
extern int __redirect___finite (double __value) __attribute__ ((__nothrow__ )) __attribute__ ((__const__));
[...]
extern int __redirect___finitef (float __value) __attribute__ ((__nothrow__ )) __attribute__ ((__const__));
[...]
extern int __redirect___finitel (long double __value) __attribute__ ((__nothrow__ )) __attribute__ ((__const__));
[...]
extern int __redirect___finitef128 (_Float128 __value) __attribute__ ((__nothrow__ )) __attribute__ ((__const__));

(from the multiple inclusions of mathcalls-helper-functions.h (see comment
about the differences between s_finite.c and s_finitef.c further down this
message))

But include/math.h declares hidden prototypes for them (snippet):

# 9 "../include/math.h" 2
[...]
extern __typeof (__redirect___finite) __redirect___finite __attribute__ ((visibility ("hidden")));
[...]
extern __typeof (__redirect___finitef) __redirect___finitef __attribute__ ((visibility ("hidden")));
[...]
extern __typeof (__redirect___finitel) __redirect___finitel __attribute__ ((visibility ("hidden")));
[...]
extern __typeof (__finitef128) __finitef128 __attribute__ ((visibility ("hidden")));
                 ~~~~~~~~~~~
Here's the source of the error.


As for the difference between s_finite.c and s_finitef.c, that happens
because include/math.h includes math/math.h before creating the hidden
prototypes.

On top of that, math/math.h includes bits/mathcalls-helper-functions.h
(once for each floating-point type).  However, the declarations in
bits/mathcalls-helper-functions.h are macroized using __MATHDECL_1.
__MATHDECL_1 receives the suffix (f, l, f128, or nothing) as a parameter
and expands the base name (e.g.: __finite).

When s_finite.c defines __finite as __redirect_finite, all declarations in
bits/mathcalls-helper-functions.h are also redefined.  That doesn't happen
with s_finitef.c because it only defines __finitef, which does not match
with anything in bits/mathcalls-helper-functions.h.
  

On Fri, 8 Sep 2017, Gabriel F. T. Gomes wrote:

> On top of that, math/math.h includes bits/mathcalls-helper-functions.h
> (once for each floating-point type).  However, the declarations in
> bits/mathcalls-helper-functions.h are macroized using __MATHDECL_1.
> __MATHDECL_1 receives the suffix (f, l, f128, or nothing) as a parameter
> and expands the base name (e.g.: __finite).
> 
> When s_finite.c defines __finite as __redirect_finite, all declarations in
> bits/mathcalls-helper-functions.h are also redefined.  That doesn't happen
> with s_finitef.c because it only defines __finitef, which does not match
> with anything in bits/mathcalls-helper-functions.h.

I think that this key point - that the function name gets macro expanded 
before the concatenation - needs explaining in comments in all three 
affected source files to justify why they are defining the macros for 
other types.