Re: [RFC] tgmath.h and math/Makefile refactor

[Joseph Myers <joseph at codesourcery dot com>]

On Wed, 8 Jun 2016, Paul E. Murphy wrote:

> By tacit agreement, the community does not object to adding support for
> new types and functioned outlined by TS 18661.  For practical reasons,

Subject to consensus on the precise set to be added - this does not mean 
arbitrary subsets should be added in isolation.  Hence the attempt to 
define things in terms of all the TS 18661-3 interfaces for _Float128 
(functions and others) where glibc has the corresponding interfaces for 
other types, plus analogues of other glibc interfaces to be determined 
case-by-case.

> > 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 
> > types.
> >
> 
> Is the intent to avoid linking libm when using the classification
> macros on a compiler without a builtin, a side effect of their usage
> in std* functions, or something else?

I think some functions are included in libc because of use elsewhere in 
libc (e.g. in stdio) of classification macros.  It's possible the 
underlying functions are not all now used in libc since we moved to using 
__builtin_* for the classification macros where possible in the absence of 
-fsignaling-nans and moved to using those macros in glibc code instead of 
calling __* directly (but it's also possible we'll find a need in future 
to build bits of libc with -fsignaling-nans).

I don't think there's any goal to avoid linking libm for user code using 
these macros.

Exporting functions from multiple libraries is confusing and wasteful of 
space, hence the question of whether new functions like that should go 
only in one library (and if so, which).

> Would there be a problem defining these as static inlined functions
> to avoid the ABI?

None of the macros used in their existing implementations are in the 
implementation namespace, nor the structures used, and you'd have to deal 
with endianness issues in defining such functions/structures as well as 
the namespace issues.  It seems safer to have corresponding underlying 
functions.

> Yes, those will need to be addressed when transitioning the long double
> type.  The aliasing appears like it will get messy. Thinking out loud
> here, is it possible to isolate the mapping of the local symbols to
> public symbols to their own file/header?

Mostly, the macros used in math.h when including bits/mathcalls.h should 
be adaptable to handle rules like "redirect *l to __*f128", and similarly 
for complex.h and bits/math-finite.h.  One design question is how to 
arrange the bits/*.h headers used by architectures to describe things like 
this about how the main API headers should behave (regarding what types 
are available and what renamings should be done).

> Ideally, libc additions should be minimal, for each type:
> 
> >From TS 18661-3:
> 
> 	strto strfrom
> 
> >From GNU, keeping symmetry with
> 
> 	strfrom*_l strto*_l wscto wscto*_l
> 	wcsfrom wscfrom*_l

That seems plausible (at the API level).  *[efg]*cvt* are explicitly 
excluded as obsolescent.

At the ABI level, various implementation-namespace function versions are 
exported (with, unfortunately, a wildcard __strto*_internal in 
stdlib/Versions and a similar one in wcsmbs/Versions; we should eliminate 
such wildcards to avoid accidentally adding new functions to old 
versions).  Those include __strtold_internal __wcstold_internal 
__strtold_l __wcstold_l and others for other types.  Unless there is a 
current use for such exports (used in inline functions or macros in 
installed headers, used in libstdc++ for namespace reasons) it would be 
best to make the existing exports of such functions into compat symbols 
and then not export them for new types.  (That does mean the strto* 
grouping functionality would not be available for new types, since it's 
only available through the _internal interfaces and through scanf.)

-- 
Joseph S. Myers
joseph@codesourcery.com