Re: RFC Migrating PowerPC to IEEE 128-bit Floating Point

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

Hi Joseph,

I'd like to continue on with this discussion. You've raised a number of
valid issues we should consider before any code is modified. I really
would like to avoid spinning a one off library for PPC.

On 10/13/2015 06:11 PM, Joseph Myers wrote:

> Now, here are some examples of issues to consider in the design and 
> consensus-building process.  Where I suggest answers here, I am *not* 
> asserting that only a particular answer is acceptable - what is or is not 
> required is determined by the community through a consensus process, and 
> generally these are cases where if making such changes myself I'd still 
> want to allow for the community to reach consensus first rather than 
> acting as libm maintainer to treat something as having consensus in the 
> absence of discussion.  It's only the two principles I stated in 
> <https://sourceware.org/ml/libc-alpha/2015-09/msg00751.html> about ABI 
> compatibility requirements that I'm confident asserting as definite 
> requirements here, that are well-enough established no further discussion 
> of them is required to understand their application to this case.

If I understand you, for a PPC ABI to support __float128, the minimum
compiler version for building glibc would need to be raised to guarantee
the availability of the new ABI?

> * We need to agree that the prior rejection of __float128 support in 
> <https://sourceware.org/ml/libc-alpha/2004-03/msg00326.html> and 
> <https://sourceware.org/ml/libc-alpha/2004-05/msg00055.html> no longer 
> stands, in the light of the existence of standard C bindings in TS 
> 18661-3.  I don't think there should be any controversy about superseding 
> such an old decision, but it should still be clear that we are doing so.

Those old patches appear to attempt to basically merge libquadmath into
glibc (or do I have it wrong, and that was the genesis of quadmath?). Are
you suggesting we should be figuring out a plan to support _Float128 as
defined by TS 18661?

> 
> * We need to agree on the appropriateness of APIs from TS 18661 - that is, 
> to get consensus on a whole set of APIs being appropriate for glibc, so 
> that doesn't need redebating every time an individual new API is proposed.  
> The APIs from parts 1, 3 and 4, excluding those relating to decimal 
> floating point, seem a reasonable set to consider in such a discussion 
> (with a clear expectation that such APIs could then be added piecemeal, 
> with individual patches still needing consensus on the merits of the 
> implementation).  (If controversial, the minimal set for present purposes 
> would be the _Float128 APIs from part 3 that correspond to APIs already 
> present in glibc for other floating-point types, but I hope it would be 
> possible to obtain consensus on a wider set of APIs.)
> 
> * We need to agree on rules for ABIs corresponding to such APIs.  My 
> suggestion is: where an API meets the ISO C rules for being usable without 
> including a header, the function needs an exported symbol with the same 
> name (for example, if we support sinf128 on a platform where long double 
> is binary128, there does actually need to be a sinf128 exported symbol, 
> not just a header redirecting calls to use sinl).  But if it doesn't meet 
> such rules, the number of exported symbols should be kept to a minimum 
> (for example, functions that exist only for use by type-generic macros 
> should not have such aliases).  Functions would go in libc or libm 
> according to what header has the declaration, unless consistency with 
> existing functions dictates otherwise (e.g. __isinff128 might go in libc 
> because other __isinf* functions are there).

Are you able to point out the relevant clauses in ISO C for this? I want to
make sure I understand these rules well.

> 
> * We need to consider what to do about functions not included in TS 
> 18661-3.  Some possible cases: (a) function aliases such as drem or gamma 
> or pow10 shouldn't have *f128 versions.  (b) Obsolescent functions such as 
> scalb shouldn't either (though they'll still need long double = binary128 
> versions, but not the *f128 APIs).  (c) Where TS 18661 has clearly chosen 
> a different direction, do not add *f128 APIs for the old functions (so no 
> nexttoward or printf variants - maybe add nextdown, nextup, strfrom 
> functions instead as preparatory patches - again, long double = binary128 
> verisons will still be needed).  (d) In some cases, *f128 functions as GNU 
> APIs are clearly reasonable by analogy - for example, strtof128_l, 
> wcstof128, lgammaf128_r.  (e) As a community, we should think especially 
> carefully about what to do in cases where the above might miss some 
> functionality, e.g. support for grouping when reading strings to 
> __float128, or strfmon formatting of __float128 values (the answer might 
> well end up being that this functionality can only be accessed in the case 
> where long double = __float128).  (f) M_* constants in math.h (needed in 
> the implementations in any case).  (Part of the design process is to get a 
> *complete* list of such cases for consideration.)
> 
> * Would it be best to avoid the new interfaces supporting matherr / 
> _LIB_VERSION?  It's been discussed before that we'd like to deprecate that 
> functionality; proper deprecation could mean new symbol versions for 
> affected functions that avoid using the _LIB_VERSION global at all.  It 
> would be unfortunate to add multiple versions of *f128 in quick 
> succession, first with _LIB_VERSION support and then without.  This seems 
> desirable to discuss even if we end up concluding it's best not to make 
> this a dependency.
> 
> * Many more specific questions regarding details of the design and 
> implementation approach in different areas.
> 
> * While working on it, it's important to pay attention to how the work 
> relates to the details of TS 18661 and to ongoing discussions in WG14 and 
> to track cases where possible issues or ambiguities in TS 18661 are found 
> - and to pass such information back to WG14 for consideration when it's 
> considered whether to include parts of TS 18661 in the next revision of 
> the C standard (actually having an implementation of parts of part 3 might 
> make it more likely to be included in the next revision).