This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] tgmath.h and math/Makefile refactor
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Mon, 6 Jun 2016 14:22:07 +0000
- 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>
On Fri, 3 Jun 2016, Joseph Myers wrote:
> I don't think the division into ts-18661-calls and others is a good idea
> at all. It may make sense to have a separate variable for obsolete
> functions that should not be added for new types, but most of the
To expand further on this:
Even where a function should not be exported for new types, there's still
the issue of providing a version of it for long double if you support an
alternative long double type.
For example, say you support long double being binary128 on powerpc64le
(my understanding being that that's considered a desirable subsequent step
after the support for explicit *f128 APIs is done). Then the headers
would remap calls to long double functions to call the *f128 functions
instead[*]. And while for example scalb, taking two floating-point
arguments, is obsolescent and so no scalbf128 explicit API should be
provided, scalbl is still a supported API so should be provided for the
new long double variant - meaning that in that case you do still need to
build a version of scalb for binary128, just export it under a name such
as __scalbf128, not with a public scalbf128 name at API or ABI level.
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).
[*] Strictly ISO C would require the remapping to go to __*f128 names with
those being exported as well, to stay within the ISO C namespace;
something to consider later.
--
Joseph S. Myers
joseph@codesourcery.com