On Fri, 21 Jul 2017, Michael Meissner wrote: > The first change is to enable the C language to use _Float128 keyword (but not > __float128) without having to use the -mfloat128 option on power7-power9 > systems. My question is in the TR that introduced _Float128, is there any > expectation that outside of the built-in functions we already provide, that we > need to provide runtime functions? Yes, glibc 2.26 will be coming along > shortly, and it should provide most/all of the F128 functions, but distros > won't pick this library up for some time.
In formal standards terms, TS 18661-3 builds on TS 18661-1 (for binary floating point) or 18661-2 (for decimal floating point), both of which add the contents of <fenv.h>, <math.h> and the numeric conversion functions from <stdlib.h> to the library features required of freestanding implementations. I don't think that makes any difference to what GCC should do, however. Just as stdatomic.h is provided by GCC, though strictly a hosted library feature rather than one required of freestanding implementations, and just as GCC always requires a C library to provide memcpy / memmove / memset, even the case of a freestanding implementation requires a cooperating compiler / library pair, and in this case it makes the most sense for those library facilities (both C11 ones and newer TS 18661 ones such as for float128) to come from an external libc/libm. At some point I should update standards.texi to discuss these variations from the old rule of thumb of GCC providing exactly those library facilities required of freestanding implementations. Practically, code expecting compiler support for _Float128 to imply library support is just like code expecting __STDC_VERSION__ to imply C11 library support; people may write such code, but it's not practically portable. -- Joseph S. Myers jos...@codesourcery.com
