This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] tgmath.h and math/Makefile refactor
- From: Steven Munroe <munroesj at linux dot vnet dot ibm dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>, libc-alpha at sourceware dot org
- Date: Tue, 07 Jun 2016 13:25:03 -0500
- Subject: Re: [RFC] tgmath.h and math/Makefile refactor
- Authentication-results: sourceware.org; auth=none
- References: <563977bd-5bb8-97ed-f722-3527c600426d at linux dot vnet dot ibm dot com> <alpine dot DEB dot 2 dot 20 dot 1606032141070 dot 27605 at digraph dot polyomino dot org dot uk> <alpine dot DEB dot 2 dot 20 dot 1606061409300 dot 15183 at digraph dot polyomino dot org dot uk> <f11b35e6-73ff-fce3-59b6-6257679c2621 at linux dot vnet dot ibm dot com> <alpine dot DEB dot 2 dot 20 dot 1606062227120 dot 10972 at digraph dot polyomino dot org dot uk>
- Reply-to: munroesj at linux dot vnet dot ibm dot com
On Mon, 2016-06-06 at 22:50 +0000, Joseph Myers wrote:
> On Mon, 6 Jun 2016, Paul E. Murphy wrote:
> > So should we be asking what functions that exist for the C99 types
> > should *not* be exported for float128. Looking at the current
> > ABI, the existing functions fall into a small set of categories:
> You need to consider libc functions as well.... Some get __float128
> versions although not in TS 18661-3 (e.g. strtold_l), some don't (e.g.
> qecvt etc. - obsolescent functions that would still need building for a
> different long double format).
> > Functions defined by TS 18661-3 which are already included within
> > glibc:
> > round scalbln scalbn significand
> significand is not a TS 18661-3 function, and my inclination would be to
> consider it among the obsolescent functions not added for new
> floating-point types.
> > Likewise, GNU specific ABI/API which is used to support the
> > above which should be exported and guarded with _GNU_SOURCE:
> > exp10 clog10 j0l j1l
> > jnl lgamma?_r pow10
> > sincos y0 y1 yn
> I think pow10 should be considered an obsolete name for exp10, and not
> exported for new types.
> > Likewise, helper functions for the classification macros,
> > and likely support macros for transitioning long double:
> > __finite __fpclassify
> > __signbit __issignaling
> Plus some others that are in libc rather than libm (__isinf, __isnan).
> __finite and __signbit are in both libraries. It's not clear that being
> exported from both libraries rather than just one is desirable for new
> > Leaving us with a very small set of ABI/API which should
> > neither be defined nor exported as is, but may be
> > exposed in some capacity to support format transitions
> > of existing types:
> > drem nexttoward scalb finite gamma
> Where drem and gamma are obviously aliases for other functions that *are*
> exported for the new types, so supporting dreml and gammal for long double
> = binary128 doesn't require building extra code (and as aliases, they
> don't affect the makefiles either). Likewise finitel (alias for
> __finitef128). And indeed nexttowardl (alias for nextafterf128) - but
> nexttoward would instead need separate variants for float and double
> paired with the new long double type, much like the existing variants for
> long double = double. scalbl would involve building new code for the new
> type when used as long double, that wouldn't be built when used only as
> __float128; likewise significandl, if moved to this group of functions.
> (Note that where functions are being considered obsolete, we should make
> sure the manual documents them as such and says what API is preferred
> instead. As I previously noted, it needs to be made to document
> remainder, not drem, as the primary name for that function.)
> > > There are still some files that are never useful for new types even when
> > > those types are used as long double variants, e.g. w_lgamma_compat. But
> > > maybe it's just that one, in which case perhaps it makes more sense just
> > > to have an empty version of that file used for new types rather than
> > > splitting things in the Makefile (and for other files such as scalb that
> > > are conditionally used to have files with appropriate #if conditions
> > > determining whether they generate any code).
> > Assuming there is little objection to the mechanism I've
> > suggested for adding new types, these outliers can be added
> I'm not convinced the mechanism is sufficiently coherently defined yet. I
> think any division of the list of functions into different classes, or
> mechanism for sysdeps to add extra types, really needs justifying via
> having a subsequent patch that builds on it to add working *f128 support.
> (As opposed to refactoring how libm-calls is defined to avoid the special
> %_rl -> %l_r hack, or reducing duplication of code between types in
> math/Makefile, which can more readily be justified as cleanups on their
> own merits.)
I am not sure what you are saying here. The introduction of a new
standard is a complex task requiring interpretation, iteration and time.
Introducing a new type for the existing standards and implementation is
more straightforward effort.
I don't see a requirement for perfection in these early efforts for
enabling the new standards, because all of our understandings will
I also don't see a reason to hold up the effort to enable the addition
of new types (like _float128) and implementing the current API using
that type. The steps required to transition our platform to new (IEEE
standard) long double is already complex enough.
I would like to see a separation of concerns so that we can work both
efforts in parallel and also involve the larger community in the new