On Tue, 21 Jun 2016, Michael Meissner wrote: > > I'm now working on support for TS 18661-3 _FloatN / _FloatNx type names > > (keywords), constant suffixes and <float.h> addiitions. That will > > address, for C, the need to use modes for complex float128 (bug 32187) by > > allowing the standard _Complex _Float128 to be used. The issue would > > still apply for C++ (I'm not including any C++ support for these type > > names / constant suffixes in my patch), and for complex ibm128. > > Great! > > Of course we will need to have some solution for C++.
Since the C++-standard way of using complex numbers is std::complex, it's not clear to me that the C-compatible _Complex _Float128 needs to be particularly conveniently avilable in C++. Rather, where the C++ standard says "The effect of instantiating the template complex for any type other than float, double, or long double is unspecified. The specializations complex<float>, complex<double>, and complex<long double> are literal types (3.9).", presumably one should aim to make complex<__float128> work properly if it doesn't already. And that might internally use _Complex _Float128 in some way to call libm functions when available, much as libstdc++ currently has _GLIBCXX_USE_C99_COMPLEX. And then I suppose you'd want to make appropriate literal suffixes work as well. That's part of rather more generally making libstdc++ work with a new floating-point type; <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622> has an overview of the sorts of things involved and links to other discussions. Standard C++ support for decimal floating-point types, TR 24733, took the form of classes such as std::decimal::decimal64 rather than the C-style _Decimal64. I don't know what form C++ bindings to IEEE interchange and extended types might take, but something similar would seem natural. -- Joseph S. Myers jos...@codesourcery.com
