[Bug libstdc++/104772] New: std::numeric_limits<__float128> should be specialized

[Bug libstdc++/104772] New: std::numeric_limits<__float128> should be specialized

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772

            Bug ID: 104772
           Summary: std::numeric_limits<__float128> should be specialized
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: redi at gcc dot gnu.org
        Depends on: 99708, 98202
  Target Milestone: ---

We should provide a specialization of numeric_limits<__float128> when that type
is valid (even if is_floating_point_v<__float128> is false due to
__STRICT_ANSI__ being defined).

It might also be useful to do the same for __float80 on x86, although that's
less widely used. That could be done fairly easily:

#ifdef __SIZEOF_FLOAT80__
template<>
numeric_limits<__float80> : numeric_limits<long double> { };
#endif

For __float128 we need to define it fully. The compiler gives us the info we
need:

#define __FLT128_DECIMAL_DIG__ 36
#define __FLT128_DENORM_MIN__ 6.47517511943802511092443895822764655e-4966F128
#define __FLT128_DIG__ 33
#define __FLT128_EPSILON__ 1.92592994438723585305597794258492732e-34F128
#define __FLT128_HAS_DENORM__ 1
#define __FLT128_HAS_INFINITY__ 1
#define __FLT128_HAS_QUIET_NAN__ 1
#define __FLT128_IS_IEC_60559__ 2
#define __FLT128_MANT_DIG__ 113
#define __FLT128_MAX_10_EXP__ 4932
#define __FLT128_MAX_EXP__ 16384
#define __FLT128_MAX__ 1.18973149535723176508575932662800702e+4932F128
#define __FLT128_MIN_10_EXP__ (-4931)
#define __FLT128_MIN_EXP__ (-16381)
#define __FLT128_MIN__ 3.36210314311209350626267781732175260e-4932F128
#define __FLT128_NORM_MAX__ 1.18973149535723176508575932662800702e+4932F128

The F128 suffixes are a problem though, see PR 98202 comment 7.

Detecting __float128 reliably is blocked by PR 99708 comment 8.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98202
[Bug 98202] C++ cannot parse F128 suffix for float128 literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
[Bug 99708] __SIZEOF_FLOAT128__ not defined on powerpc64le-linux

[Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Strictly speaking, the __FLT128_* macros relate to _Float128 which is not
defined for C++ even when __float128 is (and in theory a target could have a
non-IEEE __float128 which would have different properties from _Float128).

[Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-03-03
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Oh, and likewise for __gnu_cxx::__numeric_traits_floating

[Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0

[Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.0                        |13.2

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 13.1 is being released, retargeting bugs to GCC 13.2.

[Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Perhaps we could change that
            if (cxx_dialect < cxx23)                          
              pedwarn (input_location, OPT_Wpedantic,         
                       "%<f%d%> or %<F%d%> suffix on floating constant only "
                       "available with %<-std=c++2b%> or %<-std=gnu++2b%>",
                       n, n);                                 
into
            if (cxx_dialect < cxx23 && !in_system_header_at (input_location))

[Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
That would be great :-)

[Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:f150a084e25eaa98afaf25e2211001047ecc8d44

commit r14-1433-gf150a084e25eaa98afaf25e2211001047ecc8d44
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Wed May 17 14:02:14 2023 +0100

    libstdc++: Add std::numeric_limits<__float128> specialization [PR104772]

    As suggested by Jakub in the PR, this just hardcodes the constants with
    a Q suffix, since the properties of __float128 are not going to change.

    We can only define it for non-strict modes because the suffix gives an
    error otherwise, even in system headers:

    limits:2085: error: unable to find numeric literal operator 'operator""Q'

    libstdc++-v3/ChangeLog:

            PR libstdc++/104772
            * include/std/limits (numeric_limits<__float128>): Define.
            * testsuite/18_support/numeric_limits/128bit.cc: New test.

[Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.2                        |14.0

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I've added the specialization to trunk, but as the commit msg says, it's
disabled for strict modes due to the Q suffix giving an error. Let's keep this
open until it's also specialized for strict modes.

Jakub, should I file a separate FE bug for the !system_header change you
suggested in comment 4?

[Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized

[jakub at gcc dot gnu.org]

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.

[Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Sorry, 0x1.0p-1016 * 0x1.0p-1016 * 0x1.0p-1016 obviously should have been
0x1.0p+1016 * 0x1.0p+1016 * 0x1.0p+1016, I tested it on a testcase where I used
different names etc.

[Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
And the reason for the helper functions is C++11 which would not like
temporaries in constexpr functions.

[Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:6261d10521f9fdc2a43d54b4dc365025288aa8e9

commit r14-1582-g6261d10521f9fdc2a43d54b4dc365025288aa8e9
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Mon Jun 5 16:14:29 2023 +0100

    libstdc++: Make std::numeric_limits<__float128> more portable [PR104772]

    This redefines std::numeric_limits<__float128> so that it works with
    non-GCC compilers. The previous definition didn't work with Clang, due
    to it not supporting __builtin_high_valq, __builtin_nanq, and
    __builtin_nansq. It also didn't work in strict modes, due to using Q
    literal suffixes.

    The new definition uses the Q suffixes when supported, or calculates the
    correct values using __float128 arithmetic from double values. Ideally
    the values would be defined as hexadecimal-floating-point-literals, but
    that won't work for C++14 and older.

    The only member that can't be defined this way is signaling_NaN() which
    still requires a built-in. If __builtin_nansq is not supported, try to
    use __builtin_nansf128 (with a possibly-redundant bit_cast) and if that
    isn't supported, return a quiet NaN and define has_signaling_NaN and
    is_iec754 to be false.

    libstdc++-v3/ChangeLog:

            PR libstdc++/104772
            * include/std/limits: (numeric_limits<__float128>): Define
            for __STRICT_ANSI__ as well.
            * testsuite/18_support/numeric_limits/128bit.cc: Remove
            check for __STRICT_ANSI__.

    Co-authored-by: Jakub Jelinek <jakub@redhat.com>

[Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Thanks, Jakub. That works nicely.

Fixed for GCC 14.

[Bug libstdc++/104772] std::numeric_limits<__float128> should be specialized

[meissner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772
Bug 104772 depends on bug 99708, which changed state.

Bug 99708 Summary: __SIZEOF_FLOAT128__ not defined on powerpc64le-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED