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

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 CC||sayle at gcc dot gnu.org

--- Comment #6 from Richard Biener  ---
Caused by g:5b02ed4b8768 but latent before (we missed !HONOR_INFINITIES on the
pattern).

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

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Richard Biener  ---
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 via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
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

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Pinski  ---
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

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Uroš Bizjak  ---
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 via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
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 (7ff8) and for the non-optimizing
case (I think if I read the assembly correctly).