[Bug libstdc++/114018] New: std::nexttoward is not implemented for C++23-FP-Types

[Bug libstdc++/114018] New: std::nexttoward is not implemented for C++23-FP-Types

[g.peterhoff@t-online.de]

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

            Bug ID: 114018
           Summary: std::nexttoward is not implemented for C++23-FP-Types
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: g.peterhoff@t-online.de
  Target Milestone: ---

please see https://godbolt.org/z/EoKnEE8eT

thx
Gero

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This depends on the version of glibc to include the c version of these
functions.  So this is most likely just an artifact of not having a new enough
glibc.

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So if godbolt uses an older version of glibc for x86_64 then report it to them
not us.

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-02-20
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I don't think that's right, we don't have any std::nexttoward for those types
at all, irrespective of what glibc has. IIRC this was noted as missing when
Jakub implemented the types.

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

[jsm28 at gcc dot gnu.org]

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

--- Comment #4 from Joseph S. Myers <jsm28 at gcc dot gnu.org> ---
I don't know what's expected for C++, but for C, TS 18661-3 and C23 don't have
versions of nexttoward for _FloatN or _FloatNx (recall that the second argument
of nexttoward has type long double independent of the first argument, which is
using long double as a common superset type for all the standard floating types
- but no such common superset type is guaranteed to exist for all the _FloatN
and _FloatNx types, and long double certainly need not be such a type, so
nexttoward doesn't make sense for _FloatN or _FloatNx). Instead, those types
have nextafter, nextup and nextdown functions.

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If you want a function with 2 arguments of the same type, that is
std::nextafter.
In C, nexttoward{f,,l} has first argument of float, double and long double, so
the last one is always long double.
Now, https://eel.is/c++draft/cmath.syn lists
constexpr floating-point-type nextafter(floating-point-type x,
floating-point-type y);
constexpr float nextafterf(float x, float y);
constexpr long double nextafterl(long double x, long double y);
which is correct and
constexpr floating-point-type nexttoward(floating-point-type x, long double y);
constexpr float nexttowardf(float x, long double y);
constexpr long double nexttowardl(long double x, long double y);
which I believe is a bug in the standard, finding next representable number in
direction of long double which might have smaller or uncomparable precision or
range doesn't make much sense.
See
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602667.html
for more details.  At that point it was
constexpr floating-point-type nexttoward(floating-point-type x,
floating-point-type y);
constexpr float nexttowardf(float x, long double y);
constexpr long double nexttowardl(long double x, long double y);
which was also backwards incompatible change because before the C++23 changes
it was
constexpr double nexttoward(double x, long double y);
constexpr float nexttoward(float x, long double y);
constexpr long double nexttowardl(long double x, long double y);
constexpr float nexttowardf(float x, long double y);
constexpr long double nexttowardl(long double x, long double y);
What is in the standard now looks wrong to me as well, e.g. if long double is
IBM extended format and floating-point-type is std::float128_t, C++23 doesn't
even allow comparison between those two types:
error: invalid operands to binary > (have ‘_Float128’ and ‘long double’)
    4 |   return x > y;
      |          ~~^~~
and very difficult to implement, both because of that because having to handle
all possible long double representations vs. all extended floating point types.
As Joseph said in the above thread, C23 has
_FloatN nextafterfN(_FloatN x, _FloatN y);
_FloatNx nextafterfNx(_FloatNx x, _FloatNx y);
_FloatN nextupfN(_FloatN x);
_FloatNx nextupfNx(_FloatNx x);
_FloatN nextdownfN(_FloatN x);
_FloatNx nextdownfNx(_FloatNx x);
but nexttoward remains double, float and long double only.
Because nexttoward is only meaningful if long double is a superset of the other
floating point type, which is the case for float/double.

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I know cppreference is not the standard exactly but it does have the following
about nexttoward:
However, an invocation of std::nexttoward is ill-formed if the argument
corresponding to from has extended floating-point type

https://en.cppreference.com/w/cpp/numeric/math/nextafter


So maybe this is invalid after all.

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Yeah, it is hidden at the end of the page: https://eel.is/c++draft/cmath.syn#4
https://cplusplus.github.io/LWG/issue3790

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, do we need to define those and std::unreachable (); in their bodies or
something similar?

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #8)
> So, do we need to define those and std::unreachable (); in their bodies or
> something similar?

Though, cmath probably can't #include <utility>, so
#ifdef _GLIBCXX_DEBUG
    std::__glibcxx_assert_fail(nullptr, 0, "std::nexttoward with extended
floating point type", nullptr);
#elif defined _GLIBCXX_ASSERTIONS
    __builtin_trap();
#else
    __builtin_unreachable();
#endif
or something similar.
Jon, I can try to write it tomorrow if you tell me what you prefer.

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #8)
> So, do we need to define those and std::unreachable (); in their bodies or
> something similar?

No, it needs to be ill-formed to call them, which is already the case as the
godbolt example in comment 0 shows:

<source>:13:28: error: no matching function for call to 'nexttoward(const T&,
const T&)'

I think there's nothing to do here.

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
But what about following:
#include <cmath>
#include <stdfloat>

auto f = static_cast<std::float128_t (*)(std::float128_t, long
double)>(&std::nexttoward);

This doesn't call std::nexttoward(std::float128_t, long double), just checks if
it is defined.

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

[de34 at live dot cn]

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

Jiang An <de34 at live dot cn> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |de34 at live dot cn

--- Comment #12 from Jiang An <de34 at live dot cn> ---
(In reply to Jakub Jelinek from comment #11)
> But what about following:
> #include <cmath>
> #include <stdfloat>
> 
> auto f = static_cast<std::float128_t (*)(std::float128_t, long
> double)>(&std::nexttoward);
> 
> This doesn't call std::nexttoward(std::float128_t, long double), just checks
> if it is defined.

The well-formedness is currently unspecified because std::nexttoward is not
addressable (see [namespace.std]).

I think such conversion should be ill-formed and libstdc++ is currently doing
the right thing. No change needs to be done.

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Then I wonder what was the reason for the final LWG3790 revision, the middle
proposed resolution seems to be much more readable and understandable where one
could see exactly what is valid in the synopsis and if the standard attempts to
save lines,
the extra 2 lines in the synopsis are the same size as the extra paragraph
hidden at the end.

Anyway, so INVALID?

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ah, it is described in https://eel.is/c++draft/cmath.syn#2 and probably due to
https://eel.is/c++draft/cmath.syn#3 (so that one can use std::nexttoward(42,
53.0L);
as it has just one floating-point-type argument, there is no template for
promotion
of args for nexttoward).
Perhaps
constexpr standard-floating-point-type nexttoward(standard-floating-point-type
x, long double y);
and define standard-floating-point meaning in [cmath.syn]/2 and talk about it
also in
[cmath.syn]/3?

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #13)
> Then I wonder what was the reason for the final LWG3790 revision, the middle
> proposed resolution seems to be much more readable and understandable where
> one could see exactly what is valid in the synopsis and if the standard
> attempts to save lines,
> the extra 2 lines in the synopsis are the same size as the extra paragraph
> hidden at the end.

Ah, I've checked the minutes, and the reason for the final form of the wording
is that we wanted to prevent:

std::nexttoward((std::float32_t)0, 0.0L)

With the three overloads for float/double/long double (as implemented in
libstdc++ today) that would be well-formed if float is IEEE binary32. There is
an implicit conversion to float, but that means it returns a float, not a
_Float32 as you would expect it to.

Similarly for nexttoward((std::float64_t)0, 0.0L).

So we do need a change here, because we need to explicitly make that
ill-formed.

Maybe just (with suitable preprocessor checks for the types):

void nexttoward(float32_t, long double) = delete;
void nexttoward(float64_t, long double) = delete;
void nexttoward(float128_t, long double) = delete;

We could also add deleted overloads for bfloat16_t and float16_t although they
don't currently compile anyway, because the float/double/long double overloads
are ambiguous. For consistency in diagnostics, I think defining them all as
deleted would be better.

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely <redi at gcc dot gnu.org> ---
We could also just add:

#if __cplusplus > 202002L
  template<floating_point _Tp>
    void
    nexttoward(_Tp, long double) = delete;
#endif


The existing overloads would be preferred for float, double, long double and
integral types, so this would only be chosen for extended floating-point types.

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Or just:

  template<typename _Tp>
    __enable_if_t<is_floating_point<_Tp>::value>
    nexttoward(_Tp, long double) = delete;

So that it is present for C++11 and so works when _Float32 and _Float64 names
are used instead of the C++23 aliases.

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #15)
> void nexttoward(float32_t, long double) = delete;
> void nexttoward(float64_t, long double) = delete;
> void nexttoward(float128_t, long double) = delete;
> 
> We could also add deleted overloads for bfloat16_t and float16_t although
> they don't currently compile anyway, because the float/double/long double
> overloads are ambiguous. For consistency in diagnostics, I think defining
> them all as deleted would be better.

The suitable preprocessor conditions could be by placing those declarations
(of course with _Float32, _Float64, _Float128, _Float16 etc., cmath doesn't
rely on stdfloat inclusion) right after the nextafter _Float32 etc. overloads.
Anyway, if your template works properly even for the integers, even better.

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org
             Status|NEW                         |ASSIGNED
   Target Milestone|---                         |13.3
           Keywords|                            |accepts-invalid

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.3                        |13.4

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 13.3 is being released, retargeting bugs to GCC 13.4.