[Bug libquadmath/114140] New: quadmath fminq/fmaxq with signaling_NaN not work

[Bug libquadmath/114140] New: quadmath fminq/fmaxq with signaling_NaN not work

[g.peterhoff@t-online.de]

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

            Bug ID: 114140
           Summary: quadmath fminq/fmaxq with signaling_NaN not work
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libquadmath
          Assignee: unassigned at gcc dot gnu.org
          Reporter: g.peterhoff@t-online.de
  Target Milestone: ---

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

Notes:
* std::numeric_limits<__float128> (from boost) does not work properly, so I
fall back to builtins.
* std::fmin/fmax for __float128 calls fminq/fmaxq (boost, this works)

thx
Gero

[Bug libquadmath/114140] quadmath fminq/fmaxq with signaling_NaN not work

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
From what I can see, the libquadmath implementation is the same as glibc's,
which does return x + y; if either x or y is sNaN:
https://sourceware.org/git/?p=glibc.git;a=blob;f=math/s_fmax_template.c;h=01b92600c67f7774f370810a1eea456867212ce3;hb=refs/heads/master

[Bug libquadmath/114140] quadmath fminq/fmaxq with signaling_NaN not work

[jsm28 at gcc dot gnu.org]

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

--- Comment #2 from Joseph S. Myers <jsm28 at gcc dot gnu.org> ---
Returning a quiet NaN when either argument is a signaling NaN is correct at
least for C (fmin/fmax correspond to IEEE 754-2008 operations, *not* the new
IEEE 754-2019 operations which are
fminimum/fmaximum/fminimum_num/fmaximum_num).

This is not a self-contained bug report ("not work" doesn't say what was
expected or why).  But the output reported from the godbolt link is

std::float128_t
inf
inf
inf
inf

__float128
inf
inf
nan
nan

which looks correct for __float128 and incorrect for float128_t (suggesting
that, in the float128_t case, something might have wrongly converted the
signaling NaN to a quiet NaN before calling the underlying function).

[Bug middle-end/114140] quadmath fminq/fmaxq with signaling_NaN not work

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|libquadmath                 |middle-end

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This has nothing to do quadmath But rather the builtins and constant folding.
As shown by:


```
_Float128 f1()
{

        using T = _Float128;
        //using L = std::numeric_limits<T>;
        const T
            a = __builtin_huge_valf128(),
            b = __builtin_nanf128(""),
            c = __builtin_nansf128("");
  return __builtin_fminf128(a, b);
}
_Float128 f2()
{

       //using T = std::float128_t;
        using T = _Float128;
     //   using L = std::numeric_limits<T>;
        const T
            a = __builtin_huge_valf128(),
            b = __builtin_nanf128(""),
            c = __builtin_nansf128("");
  return __builtin_fmaxf128(a, b);
}
_Float128 f3()
{
       //using T = std::float128_t;
        using T = _Float128;
      //  using L = std::numeric_limits<T>;
        const T
            a = __builtin_huge_valf128(),
            b = __builtin_nanf128(""),
            c = __builtin_nansf128("");
  return __builtin_fminf128(a, c);
}
_Float128 f4()
{

       //using T = std::float128_t;
        using T = _Float128;
     //   using L = std::numeric_limits<T>;
        const T
            a = __builtin_huge_valf128(),
            b = __builtin_nanf128(""),
            c = __builtin_nansf128("");
  return __builtin_fmaxf128(a, c);
}
```

[Bug middle-end/114140] fmin/fmax with signaling_NaN not work

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|quadmath fminq/fmaxq with   |fmin/fmax with
                   |signaling_NaN not work      |signaling_NaN not work

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
With `-fsignaling-nans` added, then we get the :
inf
inf
nan
nan

so ...

Even using float instead also cause the same output:
```
#include <type_traits>
#include <iostream>
#include <stdfloat>
#include <limits>
#include <cmath>

int main()
{
    {
        using T = float;
        using L = std::numeric_limits<T>;
        const T
            a = L::infinity(),
            b = L::quiet_NaN(),
            c = L::signaling_NaN();

        std::cout << "float\n";
        std::cout << std::fmin(a, b) << std::endl;
        std::cout << std::fmax(a, b) << std::endl;
        std::cout << std::fmin(a, c) << std::endl;
        std::cout << std::fmax(a, c) << std::endl;
    }
}
```

So Looks like we convert sNaN to qNan if `-fsignaling-nans` is not supplied ...

[Bug middle-end/114140] fmin/fmax with signaling_NaN not work

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
At least on the godbolt link, if I add -fsignaling-nans option, it prints
inf/inf/nan/nan for both types.
So, in that case it looks like a non-bug to me.
fmaxq/fminq get the same behavior regardless of the option simply because
fmaxq/fminq aren't builtins and so aren't constant folded.

[Bug middle-end/114140] fmin/fmax with signaling_NaN not work

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So with `-fsignaling-nans` we don't constant fold fmin*/fmax* any more.

[Bug middle-end/114140] different results for std::fmin/std::fmax and quadmath fminq/fmaxq if one argument=signaling_NaN

[g.peterhoff@t-online.de]

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

--- Comment #7 from g.peterhoff@t-online.de ---
I think there is a misunderstanding. The problem is that std::fmin/std::fmax
and quadmath fminq/fmaxq give different results when only *one* argument is
signaling_NaN.
The standard (https://en.cppreference.com/w/cpp/numeric/math/fmin +
https://en.cppreference.com/w/cpp/numeric/math/fmax) says:
* If one of the two arguments is NaN, the value of the other argument is
returned
* Only if both arguments are NaN, NaN is returned

quadmath fminq/fmaxq also return NaN if only *one* argument is signaling_NaN.

[Bug libquadmath/114140] different results for std::fmin/std::fmax and quadmath fminq/fmaxq if one argument=signaling_NaN

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to g.peterhoff from comment #7)
> I think there is a misunderstanding. The problem is that std::fmin/std::fmax
> and quadmath fminq/fmaxq give different results when only *one* argument is
> signaling_NaN.
> The standard (https://en.cppreference.com/w/cpp/numeric/math/fmin +
> https://en.cppreference.com/w/cpp/numeric/math/fmax) says:
> * If one of the two arguments is NaN, the value of the other argument is
> returned
> * Only if both arguments are NaN, NaN is returned
> 
> quadmath fminq/fmaxq also return NaN if only *one* argument is signaling_NaN.

As I can show this is not just about quadmath either. glibc's fminf/fmaxf has
the same behavior there.

[Bug libquadmath/114140] different results for std::fmin/std::fmax and quadmath fminq/fmaxq if one argument=signaling_NaN

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://sourceware.org/bugz
                   |                            |illa/show_bug.cgi?id=20947

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #8)
> As I can show this is not just about quadmath either. glibc's fminf/fmaxf
> has the same behavior there.

https://sourceware.org/bugzilla/show_bug.cgi?id=20947

[Bug libquadmath/114140] different results for std::fmin/std::fmax and quadmath fminq/fmaxq if one argument=signaling_NaN

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to g.peterhoff from comment #7)
> I think there is a misunderstanding. The problem is that std::fmin/std::fmax
> and quadmath fminq/fmaxq give different results when only *one* argument is
> signaling_NaN.
> The standard (https://en.cppreference.com/w/cpp/numeric/math/fmin +
> https://en.cppreference.com/w/cpp/numeric/math/fmax) says:
> * If one of the two arguments is NaN, the value of the other argument is
> returned
> * Only if both arguments are NaN, NaN is returned
> 
> quadmath fminq/fmaxq also return NaN if only *one* argument is signaling_NaN.

The cppreference page is wrong.
See https://sourceware.org/bugzilla/show_bug.cgi?id=20947 for reference on why.

[Bug libquadmath/114140] different results for std::fmin/std::fmax and quadmath fminq/fmaxq if one argument=signaling_NaN

[pinskia at gcc dot gnu.org]

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

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
And see https://sourceware.org/bugzilla/show_bug.cgi?id=26045 .

[Bug libquadmath/114140] different results for std::fmin/std::fmax and quadmath fminq/fmaxq if one argument=signaling_NaN

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://sourceware.org/bugz
                   |                            |illa/show_bug.cgi?id=26045

--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Specifically  https://sourceware.org/bugzilla/show_bug.cgi?id=26045#c4 :
(The ISO C convention that "NaN" means 
"quiet NaN" by default may not be the most helpful to readers.  We do 
refer to the fmax handling of signaling NaNs in the documentation of 
FE_SNANS_ALWAYS_SIGNAL.

So basically libquadmath is correct for signaling NaNs and maybe the constant
folding of GCC is incorrect though I am not 100% sure if -fsignaling-nans
should not make a difference or not.

[Bug libquadmath/114140] different results for std::fmin/std::fmax and quadmath fminq/fmaxq if one argument=signaling_NaN

[g.peterhoff@t-online.de]

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

--- Comment #13 from g.peterhoff@t-online.de ---
> The cppreference page is wrong.
But then *all* of your implementations for fmin/fmax (float, double, long
double, std::floatN_t) would be wrong, because they give exactly the results as
described on cppreference.
Is this really the case (which I don't believe)? And if so, that still doesn't
solve the original problem: std::math-functions and quadmath-functions *must*
of course return the same results - no matter which implementation is correct.

[Bug libquadmath/114140] different results for std::fmin/std::fmax and quadmath fminq/fmaxq if one argument=signaling_NaN

[pinskia at gcc dot gnu.org]

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

--- Comment #14 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to g.peterhoff from comment #13)
> > The cppreference page is wrong.
> But then *all* of your implementations for fmin/fmax (float, double, long
> double, std::floatN_t) would be wrong, because they give exactly the results
> as described on cppreference.
> Is this really the case (which I don't believe)? And if so, that still
> doesn't solve the original problem: std::math-functions and
> quadmath-functions *must* of course return the same results - no matter
> which implementation is correct.

Again read what I mentioned, adding -fsignaling-nans changes the behavior of
std::fmin/fmax even for float/double,etc.
As I mentioned, it is about constant folding of fmin (inside the compiler) vs
what the function actually does.

> Is this really the case (which I don't believe)? 

You can test it yourself by changing const to volatile and you will see it is
different in the middle-end's constant folding vs libc's version.

libc (and libquadmath) version is correct based on those 2 sourceware issues.
The question becomes is the constant folding version correct without
-fsignaling-nans ?

[Bug libquadmath/114140] different results for std::fmin/std::fmax and quadmath fminq/fmaxq if one argument=signaling_NaN

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's the old argument on whether isnan(NaN) should return true or false with
-ffinite-math-only.  With what we currently do "constant folding" sNaN into NaN
would be correct with -fno-signalling-nans, likewise constant folding Inf into
42.0 is "correct" for -ffinite-math-only.

You are basically invoking undefined beavior when introducing sNaN into a
program without using -fsignalling-nans.

[Bug libquadmath/114140] different results for std::fmin/std::fmax and quadmath fminq/fmaxq if one argument=signaling_NaN

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |documentation
                 CC|                            |xry111 at gcc dot gnu.org

--- Comment #16 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #15)
> It's the old argument on whether isnan(NaN) should return true or false with
> -ffinite-math-only.  With what we currently do "constant folding" sNaN into
> NaN would be correct with -fno-signalling-nans, likewise constant folding
> Inf into 42.0 is "correct" for -ffinite-math-only.
> 
> You are basically invoking undefined beavior when introducing sNaN into a
> program without using -fsignalling-nans.

Then we should make it more clear in invoke.texi.  Currently the doc is
implying the worst consequence using sNaN with -fno-signalling-nans is
"changing the number of raised exceptions."

[Bug libquadmath/114140] different results for std::fmin/std::fmax and quadmath fminq/fmaxq if one argument=signaling_NaN

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Xi Ruoyao from comment #16)
> (In reply to Richard Biener from comment #15)
> > It's the old argument on whether isnan(NaN) should return true or false with
> > -ffinite-math-only.  With what we currently do "constant folding" sNaN into
> > NaN would be correct with -fno-signalling-nans, likewise constant folding
> > Inf into 42.0 is "correct" for -ffinite-math-only.
> > 
> > You are basically invoking undefined beavior when introducing sNaN into a
> > program without using -fsignalling-nans.
> 
> Then we should make it more clear in invoke.texi.  Currently the doc is
> implying the worst consequence using sNaN with -fno-signalling-nans is
> "changing the number of raised exceptions."

Yeah, the options that are not enabled by default (-fno-signalling-nans,
-fno-trapping-math) could see improvement here.

Usually -fno-X enables optimizations that would be invalid when X happens/is
present.  But that is nothing else than giving a free ticked to undefined
behavior, maybe "constrained undefined behavior", but I'm not 100% sure we'd
live up to that.

Aka isnan (NaN) is optimized to false with -ffinite-math-only, something
that's not valid when non-finite numbers are present.  Whether doing
so for literal NaN is "nice" remains questionable, but it's at least
consistent with the behavior of x = NaN; isnan (x);

So similarly -fno-signaling-nans enables optimizations that are not
valid when sNaNs are present.  Indeed "optimizations that may change the number
of exceptions visible with signaling NaNs" is over-promising even if
effectively this is all that happens.