[Bug c/104389] New: HUGE_VAL * 0.0 is no longer a NaN

[Bug c/104389] New: HUGE_VAL * 0.0 is no longer a NaN

[vstinner at redhat dot com]

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

            Bug ID: 104389
           Summary: HUGE_VAL * 0.0 is no longer a NaN
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vstinner at redhat dot com
  Target Milestone: ---

Created attachment 52352
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52352&action=edit
Reproducer: huge_val_0_nan.c

The Python project uses "HUGE_VAL * 0" to get a Not-a-Number (NaN) double
value. Pseudo-code:

#define Py_NAN (Py_HUGE_VAL * 0.)
double my_nan(void)
{ return Py_NAN; }

Until Fedora gcc-12.0.1-0.4.fc36.x86_64
(03182470d2d2b272f06500184acab6b8ed78d8ad), it worked well.

With Fedora gcc-12.0.1-0.5.fc36.x86_64
(fb6057a2be99e071993fb54a5d338ab0febba8ff), my_nan() now returns zero (0.0).

Try attached huge_val_0_nan.c.

gcc-12.0.1-0.5.fc36.x86_64 output:
---
(1) Compute HUGE_VAL * 0 in the C compiler
isnan? 0
bytes: [0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00]

(2) Compute HUGE_VAL * 0 at runtime
isnan? 1
bytes: [0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xfffffff8, 0xffffffff]
---

gcc-11.2.1-7.fc35.x86_64 output:
---
(1) Compute HUGE_VAL * 0 in the C compiler
isnan? 1
bytes: [0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xfffffff8, 0x7f]

(2) Compute HUGE_VAL * 0 at runtime
isnan? 1
bytes: [0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xfffffff8, 0xffffffff]
---

In Python, Py_NAN is defined as "#define Py_NAN (Py_HUGE_VAL * 0.)" at:

https://github.com/python/cpython/blob/bf95ff91f2c1fc5a57190491f9ccdc63458b089e/Include/pymath.h#L60

FYI diff of the Fedora package between -4 and -5, the most important part if
the Git commit which changed ;-)

https://src.fedoraproject.org/rpms/gcc/c/398138b5f3809856b98eb4241b3c9f70da3fce9b?branch=rawhide

[Bug c/104389] [10/11/12 Regression] HUGE_VAL * 0.0 is no longer a NaN

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org
           Priority|P3                          |P1
   Target Milestone|---                         |10.4
            Summary|HUGE_VAL * 0.0 is no longer |[10/11/12 Regression]
                   |a NaN                       |HUGE_VAL * 0.0 is no longer
                   |                            |a NaN

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r12-6959-g34afa19d29c5bf0b0f504e4d0aca4e9a8bc82c5c
which has been backported to 10/11 as well.

[Bug c/104389] [10/11/12 Regression] HUGE_VAL * 0.0 is no longer a NaN

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
double foo (void) { return __builtin_huge_val () * 0.0; }
folds since r12-6959 to return 0.0 instead of return NAN; already in original
dump.

[Bug c/104389] [10/11/12 Regression] HUGE_VAL * 0.0 is no longer a NaN

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Changing it to
double
foo (void)
{
  double a = __builtin_huge_val ();
  return a * 0.0;
}
shows ccp1 applies
/* Maybe fold x * 0 to 0.  The expressions aren't the same
   when x is NaN, since x * 0 is also NaN.  Nor are they the
   same in modes with signed zeros, since multiplying a
   negative value by 0 gives -0, not +0.  */
(simplify
 (mult @0 real_zerop@1)
 (if (!tree_expr_maybe_nan_p (@0)
      && !tree_expr_maybe_real_minus_zero_p (@0)
      && !tree_expr_maybe_real_minus_zero_p (@1))
  @1))
So the question is why tree_expr_maybe_nan_p isn't true.

[Bug c/104389] [10/11/12 Regression] HUGE_VAL * 0.0 is no longer a NaN

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ah, of course it isn't NAN, it is infinity, but +-Inf * 0 is still NAN.

[Bug tree-optimization/104389] [10/11/12 Regression] HUGE_VAL * 0.0 is no longer a NaN

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52353
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52353&action=edit
gcc12-pr104389.patch

Untested fix.

[Bug tree-optimization/104389] [10/11/12 Regression] HUGE_VAL * 0.0 is no longer a NaN

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse <glisse at gcc dot gnu.org> ---
Not this bug, but note that the comment and the code don't match in this
transformation: "a negative value" becomes !tree_expr_maybe_real_minus_zero_p
(@0) which is quite different. I am not sure the path with a negative @0 for
which tree_expr_maybe_real_minus_zero_p returns false can be reached though.

[Bug tree-optimization/104389] [10/11/12 Regression] HUGE_VAL * 0.0 is no longer a NaN

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

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

commit r12-7072-gb3763384a1f696260f3ee7bda8c0e7e4ad732ad9
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Feb 5 10:52:19 2022 +0100

    match.pd: Fix x * 0.0 -> 0.0 folding [PR104389]

    The recent PR95115 change to punt in const_binop on folding operation
    with non-NaN operands into NaN if flag_trapping_math broke the following
    testcase, because the x * 0.0 simplification punts just if
    x maybe a NaN (because NaN * 0.0 is NaN not 0.0) or if one of the operands
    could be negative zero.  But Inf * 0.0 or -Inf * 0.0 is also NaN, not
    0.0, so when NaNs are honored we need to punt for possible infinities too.

    2022-02-05  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/104389
            * match.pd (x * 0 -> 0): Punt if x maybe infinite and NaNs are
            honored.

            * gcc.dg/pr104389.c: New test.

[Bug tree-optimization/104389] [12 Regression] HUGE_VAL * 0.0 is no longer a NaN

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[10/11/12 Regression]       |[12 Regression] HUGE_VAL *
                   |HUGE_VAL * 0.0 is no longer |0.0 is no longer a NaN
                   |a NaN                       |
   Target Milestone|10.4                        |12.0
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Turns out this isn't a problem on 10/11 branches.

[Bug tree-optimization/104389] [12 Regression] HUGE_VAL * 0.0 is no longer a NaN

[xry111 at mengyan1223 dot wang]

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

Xi Ruoyao <xry111 at mengyan1223 dot wang> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at mengyan1223 dot wang

--- Comment #9 from Xi Ruoyao <xry111 at mengyan1223 dot wang> ---
I think I need to paste my reply in gcc-patches here as a notice:

> Sorry for the trouble, but some warning here: even with this patch
> applied, Python would still need to replace inf * 0.0 with nan("") or
> something.  Now with folding for inf * 0.0 disabled, the multiplication
> will be evaluated at runtime and raise FE_INVALID, which is likely
> unwanted by Python.  However, raising FE_INVALID is the correct behavior
> no matter if we like or dislike it...