[Bug c/103406] New: gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above

[Bug c/103406] New: gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above

[shaohua.li at inf dot ethz.ch]

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

            Bug ID: 103406
           Summary: gcc -O0 behaves differently on "DBL_MAX related
                    operations" than gcc -O1 and above
           Product: gcc
           Version: 11.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: shaohua.li at inf dot ethz.ch
  Target Milestone: ---

Hi there,

I found that for a piece of code, gcc would give out different results when
compiled with different opt flags.

- gcc version: 11.1.0

- Platform: Ubuntu 20.04, x86_64

$gcc a.c -O0; ./a.out
nan
$
$
$gcc a.c -O1; ./a.out
-nan
$
$
$cat a.c

#include <stdio.h>
#include <float.h>

#define INFINITY (DBL_MAX+DBL_MAX)
#define NAN (INFINITY-INFINITY)

void main() {
  double x = -NAN;
  double y = NAN;
  double z = x + y;
  printf("%lf\n", z);
}

[Bug c/103406] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This is interesting.
The trunk does 0.0 for both -O0 and -O1.
ICC also does 0.0 for both -O0 and -O1 and -0.0 for -O2.
clang does -nan for -O1, -O2 and -O0

MSVC does nan for /O2 and /O1 (7ff8000000000000) and for the non-optimizing
case (I think if I read the assembly correctly).

[Bug c/103406] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak <ubizjak at gmail dot com> ---
gcc/libgcc/config/i386/sfp-machine.h says:

/* Here is something Intel misdesigned: the specs don't define
   the case where we have two NaNs with same mantissas, but
   different sign. Different operations pick up different NaNs.  */

[Bug c/103406] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Hmm, the trunk is constant folding (maybe wrong?).

We used to get for 11.1.0:
  _1 = 1.79769313486231570814527423731704356798070567525844996599e+308 *
2.0e+0;
  _2 = 1.79769313486231570814527423731704356798070567525844996599e+308 *
2.0e+0;
  _3 = _1 - _2;
  x_6 = -_3;

But now we get 0.0.

[Bug c/103406] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
           Keywords|                            |wrong-code
   Last reconfirmed|                            |2021-11-24

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Already .original at -O0 has

    double x = -0.0;
    double y = 0.0;
    double z = x + y;
  printf ((const char * restrict) "%lf\n", z);

[Bug c/103406] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
We are folding

(1.79769313486231570814527423731704356798070567525844996599e+308 * 2.0e+0) -
(1.79769313486231570814527423731704356798070567525844996599e+308 * 2.0e+0)

to 0.0 via

(simplify
 (minus @0 @0)
 (if (!FLOAT_TYPE_P (type) || !tree_expr_maybe_nan_p (@0))
  { build_zero_cst (type); }))

but appearantly even Inf - Inf is not zero.

[Bug c/103406] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Caused by g:5b02ed4b8768 but latent before (we missed !HONOR_INFINITIES on the
pattern).

[Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|gcc -O0 behaves differently |[12 Regression] gcc -O0
                   |on "DBL_MAX related         |behaves differently on
                   |operations" than gcc -O1    |"DBL_MAX related
                   |and above                   |operations" than gcc -O1
                   |                            |and above
          Component|c                           |middle-end
   Target Milestone|---                         |12.0

[Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |roger at nextmovesoftware dot com
           Assignee|unassigned at gcc dot gnu.org      |roger at nextmovesoftware dot com
             Status|NEW                         |ASSIGNED

--- Comment #7 from Roger Sayle <roger at nextmovesoftware dot com> ---
I'm currently bootstrapping and regression testing this fix:
 (simplify
  (minus @0 @0)
- (if (!FLOAT_TYPE_P (type) || !tree_expr_maybe_nan_p (@0))
+ (if (!FLOAT_TYPE_P (type)
+      || (!tree_expr_maybe_nan_p (@0)
+         && !tree_expr_maybe_infinite_p (@0)))
   { build_zero_cst (type); }))

[Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
And the -nan vs. nan is because we fold x + -y to x - y:

/* We can't reassociate at all for saturating types.  */
(if (!TYPE_SATURATING (type))

 /* Contract negates.  */
 /* A + (-B) -> A - B */
 (simplify
  (plus:c @0 (convert? (negate @1)))
  /* Apply STRIP_NOPS on the negate.  */
  (if (tree_nop_conversion_p (type, TREE_TYPE (@1))
       && !TYPE_OVERFLOW_SANITIZED (type))
   (with
    {
     tree t1 = type;
     if (INTEGRAL_TYPE_P (type)
         && TYPE_OVERFLOW_WRAPS (type) != TYPE_OVERFLOW_WRAPS (TREE_TYPE (@1)))
       t1 = TYPE_OVERFLOW_WRAPS (type) ? type : TREE_TYPE (@1);
    }
    (convert (minus (convert:t1 @0) (convert:t1 @1))))))

all the negate contracting misses HONOR_SIGNED_ZEROS/HONOR_NANS checking?
Not sure if they are really a problem for signed zeros?  If so we should
try to get a testcase for that as well.

diff --git a/gcc/match.pd b/gcc/match.pd
index 5adcd6bd02c..9cdd113e02c 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -2471,7 +2473,8 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
   (plus:c @0 (convert? (negate @1)))
   /* Apply STRIP_NOPS on the negate.  */
   (if (tree_nop_conversion_p (type, TREE_TYPE (@1))
-       && !TYPE_OVERFLOW_SANITIZED (type))
+       && !TYPE_OVERFLOW_SANITIZED (type)
+       && (!FLOAT_TYPE_P (type) || !tree_expr_maybe_nan_p (@1)))
    (with
     {
      tree t1 = type;
@@ -2484,7 +2487,8 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  (simplify
   (minus @0 (convert? (negate @1)))
   (if (tree_nop_conversion_p (type, TREE_TYPE (@1))
-       && !TYPE_OVERFLOW_SANITIZED (type))
+       && !TYPE_OVERFLOW_SANITIZED (type)
+       && (!FLOAT_TYPE_P (type) || !tree_expr_maybe_nan_p (@1)))
    (with
     {
      tree t1 = type;

btw, that doesn't fix it since combine will happily contract the negate as
well:

-   10: {r88:DF=-r83:DF;use r89:V2DF;clobber flags:CC;}
-      REG_DEAD r89:V2DF
-      REG_UNUSED flags:CC
-   11: r90:DF=r88:DF+r83:DF
-      REG_DEAD r88:DF
+    9: NOTE_INSN_DELETED
+   10: NOTE_INSN_DELETED
+   11: r90:DF=r83:DF-r83:DF

[Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
simplify_binary_operation_1 has

      /* ((-a) + b) -> (b - a) and similarly for (a + (-b)).  These
         transformations are safe even for IEEE.  */
      if (GET_CODE (op0) == NEG)
        return simplify_gen_binary (MINUS, mode, op1, XEXP (op0, 0));
      else if (GET_CODE (op1) == NEG)
        return simplify_gen_binary (MINUS, mode, op0, XEXP (op1, 0));

[Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

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

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
But I'm not sure what the stance is on the sign of NaNs

[Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above

[joseph at codesourcery dot com]

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

--- Comment #11 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
The sign of a NaN result is never specified in C except for fabs, 
copysign, negation, unary + (and assignment to the same format in the case 
where that's copy rather than convertFormat).

The result should of course be NaN (of any sign), not 0.

The reason soft-fp (and thus sfp-machine.h) has special support for 
choosing a NaN result based on NaN operands is because soft-fp is also 
used in the Linux kernel for emulating floating-point instructions, and in 
that context the aim is to follow the semantics of those instructions, 
which specifies things left unspecified in IEEE 754 and its C bindings.  
That isn't relevant at the level of C code or libgcc functions.

[Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Roger Sayle <sayle@gcc.gnu.org>:

https://gcc.gnu.org/g:6ea5fb3cc7f3cc9b731d72183c66c23543876f5a

commit r12-5529-g6ea5fb3cc7f3cc9b731d72183c66c23543876f5a
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Thu Nov 25 19:02:06 2021 +0000

    PR middle-end/103406: Check for Inf before simplifying x-x.

    This is a simple one line fix to the regression PR middle-end/103406,
    where x - x is being folded to 0.0 even when x is +Inf or -Inf.
    In GCC 11 and previously, we'd check whether the type honored NaNs
    (which implicitly covered the case where the type honors infinities),
    but my patch to test whether the operand could potentially be NaN
    failed to also check whether the operand could potentially be Inf.

    2021-11-25  Roger Sayle  <roger@nextmovesoftware.com>

    gcc/ChangeLog
            PR middle-end/103406
            * match.pd (minus @0 @0): Check tree_expr_maybe_infinite_p.

    gcc/testsuite/ChangeLog
            PR middle-end/103406
            * gcc.dg/pr103406.c: New test case.

[Bug middle-end/103406] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
           Assignee|roger at nextmovesoftware dot com  |unassigned at gcc dot gnu.org
            Summary|[12 Regression] gcc -O0     |gcc -O0 behaves differently
                   |behaves differently on      |on "DBL_MAX related
                   |"DBL_MAX related            |operations" than gcc -O1
                   |operations" than gcc -O1    |and above
                   |and above                   |
             Target|                            |x86_64

--- Comment #13 from Roger Sayle <roger at nextmovesoftware dot com> ---
The Inf - Inf => 0.0 regression should now be fixed on mainline.

Hmm.  As hinted by Richard Beiner's investigation, the underlying problem is
even more pervasive.  It turns out that on x86/IA64 chips, floating point
addition is not commutative, i.e. x+y is not the same as y+x, as demonstrated
by the test program below:

#include <stdio.h>

const double pn = __builtin_nan("");
const double mn = -__builtin_nan("");

__attribute__ ((noinline, noclone))
double plus(double x, double y)
{
  return x + y;
}

int main()
{
  printf("%lf\n",plus(pn,mn));
  printf("%lf\n",plus(mn,pn));
  return 0;
}

Output:
nan
-nan

Unfortunately, GCC assumes almost everywhere the FP addition is commutative
and (as per comments #8 and #9) associative with negation/minus.  This appears
to be target property, c.f. libgcc's _FP_CHOOSENAN, but could in theory be
resolved by a -fstrict-math mode (that implies -ftrapping-math) that disables
commutativity (swapping of operands) throughout the compiler, including
reload/fold-const etc., on affected Intel-like targets.
Perhaps this PR is a duplicate now that the regression has been fixed?

[Bug middle-end/103406] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above

[joseph at codesourcery dot com]

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

--- Comment #14 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
There is no reasonable definition of how operands of binary + map to 
particular operands of a particular instruction and so no -f or -m option 
could sensibly be defined for that.  When the result is a NaN, there is no 
requirement at all on what (quiet) NaN it is (beyond a preference for 
preservation of the payload of a NaN operand if there is at least one NaN 
operand).

[Bug middle-end/103406] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above

[roger at nextmovesoftware dot com]

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

Roger Sayle <roger at nextmovesoftware dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
             Status|NEW                         |RESOLVED

--- Comment #15 from Roger Sayle <roger at nextmovesoftware dot com> ---
I believe this is (now) a duplicate of PR target/45365.

*** This bug has been marked as a duplicate of bug 45365 ***