On Tue, 2 Jun 2015, Michael Meissner wrote: > 4) Add float128 versions of the basic math libraries. For this it will > probably be simpler if we can force long double to be IEEE 128-bit so you > don't have to change as much code, but you want to suppress whatever check > there will be to prevent user code from linking against the wrong library.
I'd say it's simpler if you don't force long double to be IEEE 128-bit (because then one answer is simply libquadmath, which already exists, to provide versions of libm functions for __float128, while making long double IEEE 128-bit affects a huge number of printf variant functions; libquadmath is a few years out of date with respect to glibc, but updating it shouldn't be hard). Building libm twice with different options seems much nastier. > Note, by the time of GCC 7.0, the C17/C++-17 standards may be final, and there > they have new names for IEEE 128-bit, etc. Since there is no project for a new major revision of the C standard (no work ongoing, no NWIP, etc.) I'm skeptical of any reference to "C17". And the last suggestion I saw referring to integration of the IEEE 754-2008 bindings into the C standard only suggested putting parts 1 and 2 in there (and even that involved some misconception about the extent to which those have been implemented). The relevant part for this is part 3, defining the _Float128 type name, functions such as sinf128, etc. Now, I think it would make sense eventually to support TS 18661 (any or all parts) in glibc, including providing the *f128 functions and so superseding libquadmath. That is, I think it would be appropriate to revisit the rejection of such support in <https://sourceware.org/ml/libc-alpha/2004-03/msg00326.html> and <https://sourceware.org/ml/libc-alpha/2004-05/msg00055.html> now appropriate standard bindings exist (but this is only my view, not a community consensus). But making the functions support building both for long double and for _Float128 would certainly be a large project. Support in accordance with TS 18661-3 would *not* involve any printf changes, since the TS 18661 approach is to use the strfrom* functions (new in part 1) for that purpose rather than e.g. adding new printf formats. -- Joseph S. Myers jos...@codesourcery.com
