Re: [PATCH v2 2/8] float128: Add _Float128 make bits to libm.

["Gabriel F. T. Gomes" <gftg at linux dot vnet dot ibm dot com>]

On Mon, 1 May 2017 12:00:31 +0000
Joseph Myers <joseph@codesourcery.com> wrote:

> The list of symbols in sysdeps/ieee754/float128/Versions is missing 
> canonicalizef128.  It's also not quite alphabetical (you have copysignf128 
> before conjf128; the __* list is rather more non-alphabetical).  It's also 
> missing exp2f128.  It's also missing fmaxmagf128 and fminmagf128.  It's 
> also missing roundevenf128.  It's also missing __exp2f128_finite.

I kept their implementations separate from this patch series in order to
ease review (since their implementation is not reusing the
implementation in ldbl-128, as is the case for all other functions).

If you prefer, I can squash those patches in this patch set and
resubmit.  Is that what you prefer?

As for the alphabetical order, I'll just fix it.

> What's the rationale for __isinff128 and __isnanf128 being in libm when 
> the versions for other types are in libc?  (For other types, __finite is 
> in both.  It's a reasonable assumption that new such functions should be 
> exported from only one library.)
> 
> Now, various such functions would have been needed in libc for use from 
> e.g. printf code (but still get built in libm even if not exported from 
> there, I think).  Mostly they may not get used in libc any more because of 
> inline expansion of macros such as isinf, together with those macros being 
> used in glibc instead of direct __isinf etc. calls.  In patch 4, you 
> arrange for __isinff128 to be used from the isinf macro when building with 
> GCC < 7, so probably __isinff128 would get used from strfromf128.

Indeed, these functions are present both in libm and libc.
They are global in libm and local in libc.

> There's a reasonable case for saying the libm is the library these 
> functions belong in and so new such functions should be exported from only 
> libm even if they need to be present in, but not exported from, libc, but 
> we should at least consider the question and make sure it's a deliberate 
> choice of where to export the functions from which will be applied in 
> future to other _FloatN / _FloatNx types.

We had assumed that these functions should be exported through libm.
From your experience, would you recommend that they be exported from
both, as is the case with the other functions?