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

[Joseph Myers <joseph at codesourcery dot com>]

On Mon, 7 Mar 2016, Paul E. Murphy wrote:

> 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?

Yes - that is, raised for all PPC platforms for which these functions are 
added to glibc - having a well defined ABI for a given library in a given 
glibc version on a given platform is a pretty fundamental principle.  And 
since certain required features (complex float128 support and a few 
built-in functions) didn't get into GCC 6, that means that the minimum 
version would be at least GCC 7 (as I noted in 
<https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02222.html>).

[There are ways of avoiding needing the complex arithmetic libgcc support 
- not much in libm uses it - but because of the other dependencies that 
will require GCC 7, and because you still need the compiler side of 
complex support, I don't think that would really help.]

This does not of course prevent much of the preparatory work being done in 
the context of supporting such functions on x86_64, say (where the 
compiler support already exists in all compilers supported for building 
glibc) - the vast bulk of that work would be necessary to support a fourth 
floating-point format on any architecture at all, and I wouldn't be 
surprised if it's a 50-patch or more series of complicated changes 
building on each other (and each of which takes several attempts to get 
right and to reach consensus).

(Given such preparation, simply adding powerpc64 to the architectures 
building float128 support would be a fairly small change, while supporting 
it as an alternative long double format - thus supporting three different 
long double formats - would be a much trickier change or series of 
changes; Jakub's original support for multiple long double formats took 
years to get in, and as I noted earlier in this discussion it still missed 
several functions that ought to have variants for different long double 
formats; getting all the cases right is hard.  Furthermore, the design of 
how that handles different printf variants with a TLS __no_long_double 
variable is not AS-safe when different parts of a program use different 
long double formats, and given the view in bug 16060 that at least dprintf 
should be AS-safe, and given that glibc reviewers pay much more attention 
to such issues than they did ten years ago, repeating that design might 
well fail to obtain consensus.)

(Given some of the preparatory work, it should be much easier to update 
libquadmath from glibc, and so get current code to users via GCC before 
the glibc ABI can be updated, than it is at present.)

> > * 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

These old patches long predate libquadmath (or at least its inclusion in 
GCC).

> you suggesting we should be figuring out a plan to support _Float128 as
> defined by TS 18661?

I think any new APIs for float128 support should follow TS 18661-3, yes 
(this doesn't mean the whole of TS 18661-3 needs supporting, where the 
corresponding float / double / long double functions aren't in glibc).  
It does need extending for at least some floating-point functions in glibc 
with no float128 analogues in TS 18661-3 - see my previous points about 
the various classes of such functions that need considering individually 
to decide whether float128 versions should be added.

Now, following TS 18661-3 means there is *nothing* in those 2004 changes 
that is actually wanted in glibc - because they deal with I/O, and TS 
18661 does not add any printf/scanf formats for new floating point types; 
rather, it uses strto* and strfrom* functions (so one or more of the 
preparatory patches in the 50-patch series would be adding the strfrom* 
functions from TS 18661-1 for the existing floating-point types, with 
thorough testcases written in a type-generic way, in preparation for later 
adding them for float128).  (And while sysdeps directory structures are 
one of the more tricky design questions, I don't think those old changes 
have anything useful regarding strto* either.)

There are certainly questions to work out regarding what extra compiler 
support might be desirable in conjunction with float128 support in glibc - 
but for now I think it's desirable to be able to build such support in 
glibc (for x86_64 etc.) with existing compilers that support the 
__float128 name but not _Float128 (and __attribute__ ((__mode__ 
((__TC__)))) for complex _Float128, etc.), although maybe with an 
expectation to phase out that support in time to simplify the code 
eventually (e.g. doing compiler support in parallel with the glibc 
support).  __float128 would become a built-in typedef for _Float128 when 
_Float128 is supported in the compiler.

> > * 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.)

Regarding such consensus, see the discussion I started at 
<https://sourceware.org/ml/libc-alpha/2015-11/msg00162.html> in an attempt 
to get consensus in advance of any implementation.  There wasn't 
opposition to the appropriateness of those APIs, but not many people 
commented either.

Note that consensus in principle for various new APIs does not mean 
consensus for completely arbitrary subsets thereof; there should be some 
coherence to the sets added.  For example, one thing to consider would be 
whether TS 18661-3 functions should first be added in cases where they 
alias existing functions (including for _Float32, _Float64, _Float32x etc. 
- and including _Float128 on architectures where it aliases the existing 
long double), with support for them as separate being later in the patch 
series.

> > * 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.

The rule about using a function without a header is in C11 7.1.4#2: 
"Provided that a library function can be declared without reference to any 
type defined in a header, it is also permissible to declare the function 
and use it without including its associated header.".  This applies to the 
vast majority of libm functions.

The rule about which library a function goes in, based on the header, 
comes from POSIX's definition of the c99 utility, saying libm is for 
functions declared in <math.h>, <complex.h> and <fenv.h>.  I think this 
continues to work fine for TS 18661 parts 1, 3 and 4.

> > * 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).

Note especially that there is a change to <tgmath.h> (for an issue I 
identified regarding different feature test macros being defined when 
different headers are included - ISO C feature test macros working 
differently from the existing glibc ones) in the floating-point working 
group's current draft of *part 2* of the TS, postdating the publication of 
parts 1 to 4, which may be relevant to part 3.  Probably the fixes in the 
current drafts will soon become DRs against the published parts of the TS.

  Changes to C11 + TS18661-1:

  To 7.25 #1, append the sentence:

  It declares function identifiers that would be declared if <math.h> and 
  <complex.h> were included by <tgmath.h>, even if <math.h> or <complex.h> 
  were included prior to <tgmath.h> in a context where the identifiers were 
  not declared.

There are implications for the design of how glibc handles declaring 
functions for different floating-point types.  It's not clear how best to 
address those.

-- 
Joseph S. Myers
joseph@codesourcery.com