https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
--- Comment #23 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Tue, 18 Nov 2014, glisse at gcc dot gnu.org wrote: > __float128 is still missing a specialization of numeric_limits. Fully supporting an extended type (whether floating-point, or one like __int128 that mostly acts like an integer type) includes (as I noted in one of the other past bug reports on such issues, bug 50441 (fixed)) typeinfo, numeric_limits (maybe with associated built-in macros), I/O and mathematical functions in general. But you may not want libstdc++ to depend on libquadmath, which may limit what you can support for __float128. (The ideal would be full C support for the relevant parts of TS 18661 in GCC and glibc, which would give you library support in libc and libm that could then be used from libstdc++ when used with glibc.) I think it would be reasonable to define built-in __FLT128_*__ macros for __float128 similar to those defined for other floating-point types (you'd then make quadmath.h use those instead of hardcoding the values directly) - and you could then use those macros in numeric_limits. That naming is in line with DTS 18661-3 defining e.g. FLT128_MANT_DIG as public names for macros relating to _Float128.
