[Bug libstdc++/101794] New: std::lerp with NaN input does not result in NaN

[Bug libstdc++/101794] New: std::lerp with NaN input does not result in NaN

[jonas.rahlf.basf at gmail dot com]

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

            Bug ID: 101794
           Summary: std::lerp with NaN input does not result in NaN
           Product: gcc
           Version: 11.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jonas.rahlf.basf at gmail dot com
  Target Milestone: ---

>From the description of std::lerp I would have expected that providing NaN as t
would result in NaN, but it does not.
The return value should be "a+t(b−a)" so if t==NaN then the result should also
be NaN.

Example:

#include <limits>
#include <cmath>
#include <iostream>

int main()
{
    constexpr float nan = std::numeric_limits<float>::quiet_NaN();
    float result = std::lerp(1, 2, nan);
    std::cout << result << std::endl;     // outputs 2
}

Yields 2, see https://godbolt.org/z/do4zEhs5o .
Compile with g++ -std=c++20.
With clang you also get 2, but with MSVC you get NaN.

[Bug libstdc++/101794] std::lerp with NaN input does not result in NaN

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The section of std::lerp in the standard does not define what value should be
returned if t is nan. I have not tried to find out what other parts of the
standard say but I think this might be just unspecified area of the standard
...

[Bug libstdc++/101794] std::lerp with NaN input does not result in NaN

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://github.com/microsof
                   |                            |t/STL/issues/65#issuecommen
                   |                            |t-563811523

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Discussion around MSVC's implementation is at 
https://github.com/microsoft/STL/issues/65#issuecomment-563811523

https://gcc.gnu.org/pipermail/gcc-patches/2019-March/518269.html
    The midpoint and lerp functions for floating point types come straight
    from the P0811R3 proposal, with no attempt at optimization.

The paper:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0811r3.html


From everything, both libstdc++v3 and libc++ implementations are still correct
but I am going to leave it up to someone else to decide that.