| Message ID | 1493415280-30534-3-git-send-email-gftg@linux.vnet.ibm.com |
|---|---|
| State | New |
| Headers | show |
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.
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?
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.)
diff --git a/math/Makefile b/math/Makefile index 97080a7..634c619 100644 --- a/math/Makefile +++ b/math/Makefile @@ -100,7 +100,7 @@ libm-compat-calls = \ # Finally, note that types is an intentionally recursive variable. # We only know the full set of supported types for the target machine # after the Rules makefile has been parsed. -types = $(type-ldouble-$(long-double-fcts)) double float +types-basic = $(type-ldouble-$(long-double-fcts)) double float # long double support type-ldouble-suffix := l @@ -117,12 +117,23 @@ type-double-routines := branred doasin dosincos halfulp mpa mpatan2 \ type-float-suffix := f type-float-routines := k_rem_pio2f +# _Float128 support +type-float128-suffix := f128 +type-float128-routines := t_sincosf128 k_sincosf128 +type-float128-yes := float128 +types = $(types-basic) $(type-float128-$(float128-fcts)) + +# For each of the basic types (float, double, long double), replace the +# occurrences of 'F' in arg 1 with the appropriate suffix for the type. +type-basic-foreach = $(foreach t, $(types-basic), \ + $(subst F,$(type-$(t)-suffix),$(1))) # Apply suffix to each type in arg 1 type-foreach = $(foreach t,$(types),$(subst F,$(type-$(t)-suffix),$(1))) libm-routines = $(strip $(libm-support) \ - $(call type-foreach, $(libm-compat-calls)) \ + $(call type-basic-foreach, \ + $(libm-compat-calls)) \ $(call type-foreach, $(libm-calls)) \ $(foreach t, $(types), $(type-$(t)-routines))) \ @@ -543,6 +554,7 @@ endif CFLAGS-s_modf.c += -fsignaling-nans CFLAGS-s_modff.c += -fsignaling-nans CFLAGS-s_modfl.c += -fsignaling-nans +CFLAGS-s_modff128.c += -fsignaling-nans # The -lieee library is actually an object file. # The module just defines the _LIB_VERSION_ variable. diff --git a/sysdeps/ieee754/float128/Makeconfig b/sysdeps/ieee754/float128/Makeconfig new file mode 100644 index 0000000..6c385d2 --- /dev/null +++ b/sysdeps/ieee754/float128/Makeconfig @@ -0,0 +1,3 @@ +# Include this earlier so it can be used earlier in Makefiles, +# and sysdep/ makefiles. +float128-fcts = yes diff --git a/sysdeps/ieee754/float128/Versions b/sysdeps/ieee754/float128/Versions new file mode 100644 index 0000000..4829102 --- /dev/null +++ b/sysdeps/ieee754/float128/Versions @@ -0,0 +1,139 @@ +%include <float128-abi.h> +%ifndef FLOAT128_VERSION +% error "float128-abi.h must define FLOAT128_VERSION" +%endif +libm { + FLOAT128_VERSION { + acosf128; + acoshf128; + asinf128; + asinhf128; + atan2f128; + atanf128; + atanhf128; + cabsf128; + cacosf128; + cacoshf128; + cargf128; + casinf128; + casinhf128; + catanf128; + catanhf128; + cbrtf128; + ccosf128; + ccoshf128; + ceilf128; + cexpf128; + cimagf128; + clog10f128; + clogf128; + copysignf128; + conjf128; + cosf128; + coshf128; + cpowf128; + cprojf128; + crealf128; + csinf128; + csinhf128; + csqrtf128; + ctanf128; + ctanhf128; + erff128; + erfcf128; + exp10f128; + expf128; + expm1f128; + fabsf128; + fdimf128; + floorf128; + fmaf128; + fmaxf128; + fminf128; + fmodf128; + frexpf128; + fromfpf128; + fromfpxf128; + getpayloadf128; + hypotf128; + ilogbf128; + j0f128; + j1f128; + jnf128; + ldexpf128; + lgammaf128; + lgammaf128_r; + llogbf128; + llrintf128; + llroundf128; + log10f128; + log1pf128; + log2f128; + logf128; + logbf128; + lrintf128; + lroundf128; + modff128; + nanf128; + nearbyintf128; + nextafterf128; + nextdownf128; + nextupf128; + powf128; + remainderf128; + remquof128; + rintf128; + roundf128; + scalblnf128; + scalbnf128; + setpayloadf128; + setpayloadsigf128; + sincosf128; + sinf128; + sinhf128; + sqrtf128; + tanf128; + tanhf128; + tgammaf128; + totalorderf128; + totalordermagf128; + truncf128; + ufromfpf128; + ufromfpxf128; + y0f128; + y1f128; + ynf128; + __acosf128_finite; + __acoshf128_finite; + __asinf128_finite; + __atan2f128_finite; + __atanhf128_finite; + __coshf128_finite; + __exp10f128_finite; + __expf128_finite; + __finitef128; + __fmodf128_finite; + __fpclassifyf128; + __gammaf128_r_finite; + __hypotf128_finite; + __iseqsigf128; + __isinff128; + __isnanf128; + __issignalingf128; + __lgammaf128_r_finite; + __log10f128_finite; + __log2f128_finite; + __logf128_finite; + __powf128_finite; + __remainderf128_finite; + __signbitf128; + __sinhf128_finite; + __sqrtf128_finite; + __j0f128_finite; + __j1f128_finite; + __jnf128_finite; + __y0f128_finite; + __y1f128_finite; + __ynf128_finite; + } +}
From: "Paul E. Murphy" <murphyp@linux.vnet.ibm.com> This adds the appropriate common bits for a platform to enable float128 and expose ABI. 2016-10-21 Paul E. Murphy <murphyp@linux.vnet.ibm.com> Gabriel F. T. Gomes <gftg@linux.vnet.ibm.com> * math/Makefile: (type-float128-suffix): New variable (type-float128-routines): Likewise (type-float128-yes): Likewise (types): Append float128 if supported (types-basic): New variable to control the use of templates for float, double, and long double, but not for float128 or newer types. (type-basic-foreach): Likewise. * sysdeps/ieee754/float128/Makeconfig: New file. * sysdeps/ieee754/float128/Versions: New file. --- math/Makefile | 16 ++++- sysdeps/ieee754/float128/Makeconfig | 3 + sysdeps/ieee754/float128/Versions | 139 ++++++++++++++++++++++++++++++++++++ 3 files changed, 156 insertions(+), 2 deletions(-) create mode 100644 sysdeps/ieee754/float128/Makeconfig create mode 100644 sysdeps/ieee754/float128/Versions