[11/12] ldbl-128ibm-compat: Redirect complex math functions

  From: Rajalakshmi Srinivasaraghavan <raji@linux.vnet.ibm.com>

The API doesn't change, i.e. compilers using a long double format compatible
with the IEEE 128-bit extended precision format are redirected from *l
functions to __*ieee128 symbols using the same mechanism already
used with -mlong-double-64 for complex math functions.

2018-06-19  Rajalakshmi Srinivasaraghavan  <raji@linux.vnet.ibm.com>

	* math/complex.h [__HAVE_DISTINCT_FLOAT128 &&
	!__HAVE_FLOAT128_UNLIKE_LDBL]: 	Redirect long double functions
	to __*ieee128.
---
 math/complex.h | 21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)
  

I don't see any test infrastructure in this patch series for either the 
math.h or complex.h functions.  Is that to be added separately?

Principles include:

* As ulps are currently identified as "ldouble" and "float128", those need 
to be appropriately associated with the correct formats in testing (which 
the testing already handles for getting _FloatN tests using the 
appropriate ulps, whatever type name those ulps may be listed with).

* The libm functions built for each format should be tested.  While most 
of the functions built for float128 are at least tested under their *f128 
names, you have those such as __significandieee128 which don't have such a 
name and so need testing added for the code to get tested at all.

* There should be at least some test coverage that the redirection works, 
i.e. tests built and run with binary128 long double.
  

Joseph Myers <joseph@codesourcery.com> writes:

> I don't see any test infrastructure in this patch series for either the 
> math.h or complex.h functions.  Is that to be added separately?

Yes.  I was planning to send it with the last patch set as it depends on
other changes to sysdeps/powerpc/powerpc64/le/Makefile.

> Principles include:
>
> * As ulps are currently identified as "ldouble" and "float128", those need 
> to be appropriately associated with the correct formats in testing (which 
> the testing already handles for getting _FloatN tests using the 
> appropriate ulps, whatever type name those ulps may be listed with).

OK.

> * The libm functions built for each format should be tested.  While most 
> of the functions built for float128 are at least tested under their *f128 
> names, you have those such as __significandieee128 which don't have such a 
> name and so need testing added for the code to get tested at all.
>
> * There should be at least some test coverage that the redirection works, 
> i.e. tests built and run with binary128 long double.

The proposal is to build all ldouble tests twice: one for -mabi=ieeelongdouble
and another for -mabi=ibmlongdouble.
So, I think both of these concerns are covered.