https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Dunno. I think you can add support even without any compiler changes, at least if _GLIBCXX_DOUBLE_IS_IEEE_BINARY64: #ifdef __STRICT_ANSI__ static _GLIBCXX_CONSTEXPR __float128 min() _GLIBCXX_USE_NOEXCEPT { return __extension__ 3.36210314311209350626267781732175260e-4932Q; } static _GLIBCXX_CONSTEXPR __float128 max() _GLIBCXX_USE_NOEXCEPT { return __extension__ 1.18973149535723176508575932662800702e+4932Q; } static _GLIBCXX_CONSTEXPR __float128 epsilon() _GLIBCXX_USE_NOEXCEPT { return __extension__ 1.92592994438723585305597794258492732e-34Q; } static _GLIBCXX_CONSTEXPR __float128 denorm_min() _GLIBCXX_USE_NOEXCEPT { return __extension__ 6.47517511943802511092443895822764655e-4966Q; } #else static _GLIBCXX_CONSTEXPR __float128 _S_1pm4088 () _GLIBCXX_USE_NOEXCEPT { return __float128 (0x1.0p-1022) * 0x1.0p-1022 * 0x1.0p-1022 * 0x1.0p-1022; } static _GLIBCXX_CONSTEXPR __float128 _S_1pm16352 () _GLIBCXX_USE_NOEXCEPT { return _S_1pm4088 () * _S_1pm4088 () * _S_1pm4088 () * _S_1pm4088 (); } static _GLIBCXX_CONSTEXPR __float128 _S_1p4064 () _GLIBCXX_USE_NOEXCEPT { return __float128 (0x1.0p+1016) * 0x1.0p-1016 * 0x1.0p-1016 * 0x1.0p-1016; } static _GLIBCXX_CONSTEXPR __float128 _S_1p16256 () _GLIBCXX_USE_NOEXCEPT { return _S_1p4064 () * _S_1p4064 () * _S_1p4064 () * _S_1p4064 (); } static _GLIBCXX_CONSTEXPR __float128 min() _GLIBCXX_USE_NOEXCEPT { return /* 0x1.0p-16382Q */ 0x1.0p-30 * _S_1pm16352 (); } static _GLIBCXX_CONSTEXPR __float128 max() _GLIBCXX_USE_NOEXCEPT { return /* 0x1.ffffffffffffffffffffffffffffp+16383Q */ (__float128 (0x1.fffffffffffffp+127) + 0x0.fffffffffffffp+75 + 0x0.ffp+23) * _S_1p16256 (); } static _GLIBCXX_CONSTEXPR __float128 epsilon() _GLIBCXX_USE_NOEXCEPT { return 0x1.0p-112; } static _GLIBCXX_CONSTEXPR __float128 denorm_min() _GLIBCXX_USE_NOEXCEPT { return /* 0x1.0p-16494Q */ 0x1.0p-142 * _S_1pm16352 (); } #endif Except that the FE errors in C++98/11/14 modes on the hexadecimal constants. I guess one could replace them with decimal constants (except those in comments of course), but better use explicit double(whatever) to make sure they aren't evaluated in higher precision. Anyway, I think the above computations should (at least assuming the decimal constants map to those hexadecimal ones) always be exact and so should produce such results in all rounding modes.