This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Tue, 2 May 2017, Gabriel F. T. Gomes wrote:

> 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).

I'd expect canonicalizef128, fmaxmagf128, fminmagf128 to be using the 
type-generic templates, just like the corresponding functions for other 
types and the other _Float128 functions using type-generic templates, with 
no special _Float128 action needed beyond just giving them appropriate 
symbol versions.

I'd expect roundevenf128 to use the ldbl-128 implementation with 
appropriate macros defined, just like the other functions based on 
ldbl-128.

That leaves exp2f128.  math/e_exp2l.c is actually logically a type-generic 
implementation that could be used for any floating-point type.  Maybe it 
should be made into a type-generic template, as long as the sysdeps 
implementations (for architectures and floating-point formats that have 
sysdeps implementations of exp2 functions) continue to be used when 
available.

> > 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?

I think exporting from libm (only) makes logical sense, given that they 
are used in macros defined in <math.h> and libm is the standard place from 
which to export any functionality from <math.h>, <complex.h> or <fenv.h>.  
It also accords with a previous discussion of how in general such 
functions should not be in, or exported from, libc.so unnecessarily 
<https://sourceware.org/ml/libc-alpha/2014-06/msg00655.html> (subject to 
requirements of compat symbols staying and the point I noted of non-compat 
copysignl being needed in libc in certain cases).

For the functions present in libc at version GLIBC_2.0, I suppose they had 
to stay exported from libc when symbol versioning was added because people 
would have had pre-symbol versioning binaries built with glibc 2.0 that 
used those functions but only linked with libc and not libm.  (Though that 
doesn't explain exports added to libc at subsequent symbol versions.)

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]