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.


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.

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.

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.

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