Re: Adding __float128 (i.e TS 18661-3) [v2]

["Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>]

The second draft for a minimum API/ABI for including
new TS 18661-3 derived typed. treat F as a stand-in
for the appropriate suffix of a declaration (i.e F ->
f128 for __float128), and f for macros.


For any new TS 18661-3 derived type, I propose the
following new functions and ABI be exposed through
libm via math.h:

	From TS 18661-3:

        acosF           [1]
        acoshF          [1]
        asinF           [1]
        asinhF
        atan2F          [1]
        atanF
        atanhF          [1]
        copysignF
        cosF
        coshF           [1]
        erfF
        erfcF
        exp2F           [1]
        expF            [1]
        expm1F
        fabsF
        fdimF
        floorF
        fmaF
        fmaxF
        fminF
        fmodF           [1]
        frexpF
        hypotF          [1]
        ilogbF
        ldexpF
        lgammaF         [2]
        llrintF
        llroundF
        log10F          [1]
        log1pF
        log2F           [1]
        logF            [1]
        logbF
        lrintF
        lroundF
        modfF
        nanF
        nearbyintF
        nextafterF
        nextdownF       [3]
        nextupF         [3]
        powF            [1]
        remainderF      [1]
        remquoF
        rintF
        roundF
        scalblnF
        scalbnF
        sinF
        sinhF           [1]
        sqrtF           [1]
        tanF
        tanhF
        tgammaF         [2]
        truncF


	From GNU:

	exp10F		[1]
	j0F		[1]
	j1F		[1]
	jnF		[1]
	lgammaF_r	[1]
	sincosF
	y0F		[1]
	y1F		[1]
	ynF		[1]

	Implementation support for the ISO C11 7.12.3
	classification macros:

        __finiteF
        __fpclassifyF
        __isinfF
        __isnanF
        __issignalingF
        __signbitF


	[1] Likewise, the following functions would
	have an equivalent __*_finite ABI entry
	for optimization:

	[2] like [1] but using inline trickery to
	redirect the call to respective _r version
	of the function to avoid exporting an extra
	symbol.  tgamma will map to
	__gammaF_r_finite to help out future long
	double transitionary work.

	[3] The float, double, and long double
	variants fall under a different feature
	test per TS 18661-1.

Likewise, through libm via complex.h:

	From TS 18661-3:

        cabsF
        cacosF
        cacoshF
        cargF
        casinF
        casinhF
        catanF
        catanhF
        cbrtF
        ccosF
        ccoshF
        ceilF
        cexpF
        cimagF
        clogF
        conjF
        cprojF
        crealF
        csinF
        csinhF
        csqrtF
        ctanF
        ctanhF
        cpowF


	From GNU:

	clog10F

Likewise, through libc via stdlib.h:

	From TS 18661-3:

	strfromF	[4]
	strtoF		[4]


	GNU variants for symmetry with both wide
	character strings and existing locale
	support:

	strfromF_l
	strtoF_l
	wsctoF
	wsctoF_l
	wcsfromF
	wscfromF_l


	[4] The float, double, and long double
	variants fall under a different feature
	test per TS 18661-1.

Macros needing altered in math.h:

	From TS 18661-3:

        fpclassify
        isfinite
        isinf
        isnan
        issignaling     [5]
        signbit


	[5] This macro is defined by TS 18661-1.
	It could be included under a slightly
	different feature test.

Macros added via math.h:

	From TS 18661-3:
	
	FP_FAST_FMAf
	HUGE_VALf


	From GNU:

        M_1_PIf
        M_2_PIf
        M_2_SQRTPIf
        M_Ef
        M_LN10f
        M_LN2f
        M_LOG10Ef
        M_LOG2Ef
        M_PIf
        M_PI_2f
        M_PI_4f
        M_SQRT1_2f
        M_SQRT2f

typedefs via math.h:

	From TS 18661-3:

	_FloatF_t	[6]

	[6] It may be obvious, but only the
	second F is a place holder.

Finally, macros via complex.h:

	From TS 18661-3:

	CMPLXf [7]

	[7] This is called out as a function
	by TS 18661-3, but ISO C11 explicitly
	names their C11 analogues as macros.

Note, the helper functions for classification macros
would *not* be exported through libc.

Likewise, matherr and _LIB_VERSION would not be supported
on these types. (Yes, this has long double transition
implications)

Likewise, tgmath.h will need updated. The selection logic
is implementation defined.  As Joseph points out, some
functions have no TS 18661-3 analogue.  I interpret the
standard to mean such macros retain their behavior prior
to TS 18661. [8]

TS 18661-3 defines a number of new macros which should be
added to float.h.  This is a compiler header, we should
avoid injecting any of these macros into a user
compilation.

It is still an open question as to how best to expose
this API.  I think the TS 18661-3 mandated __STDC_WANT_IEC_60559_TYPES_EXT__
should cover the entire non-GNU API. Likewise,
_GNU_SOURCE should only drive inclusion when used with a
proper compiler on a supported platform.


[8] Does this imply a case whereby
__STDC_WANT_IEC_60559_TYPES_EXT__ is defined, but not __STDC_WANT_IEC_60559_BFP_EXT__ within tgmath.h which
would result in next{up,down}F being declared but not
next{up,down}{f,,l} when using the next{up,down} macros?