[PATCH/2nd version] Re: nextafter() about an order of magnitude slower than trivial implementation

[Stefan Kanthak]

"Joseph Myers" <joseph@codesourcery.com> wrote:

> On Fri, 20 Aug 2021, Stefan Kanthak wrote:
> 
>>         if(ax > 0x7ffull << 53)         /* x is nan */
>>             return x;
>>         if(ay > 0x7ffull << 53)         /* y is nan */
>>             return y;
> 
> How has this been tested?  I'd have expected it to fail the nextafter 
> tests in the glibc testsuite (libm-test-nextafter.inc), because they 
> verify that sNaN arguments produce a qNaN result with the "invalid" 
> exception raised, and this looks like it would just return an sNaN 
> argument unchanged.

It doesn't look like it would, it REALLY does!
As I explicitly wrote, my changes avoid FP operations if possible.

<https://pubs.opengroup.org/onlinepubs/9699919799/functions/nextafter.html>

| If x or y is NaN, a NaN shall be returned.

I choose to return the argument NaN, what both POSIX and ISO C allow.
If my mind serves me well, one of the former editions even stated
"If an argument is NaN, this argument shall be returned". This may
but be influenced/spoiled by
<https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/nextafter-functions>

| If either x or y is a NAN, then the return value is one of the input NANs.


If that bothers you, change these 4 lines to either

         if(ax > 0x7ffull << 53)         /* x is nan */
             return 0.0 + x;
         if(ay > 0x7ffull << 53)         /* y is nan */
             return 0.0 + y;

(the addition has eventually to be guarded from optimisation) or

         if(ax > 0x7ffull << 53          /* x is nan */
         || ay > 0x7ffull << 53)         /* y is nan */
             return x + y;

whatever you like best.

Stefan