This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2 2/8] float128: Add _Float128 make bits to libm.
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "Gabriel F. T. Gomes" <gftg at linux dot vnet dot ibm dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Mon, 1 May 2017 12:00:31 +0000
- Subject: Re: [PATCH v2 2/8] float128: Add _Float128 make bits to libm.
- Authentication-results: sourceware.org; auth=none
- References: <1493415280-30534-1-git-send-email-gftg@linux.vnet.ibm.com> <1493415280-30534-3-git-send-email-gftg@linux.vnet.ibm.com>
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