[Bug rtl-optimization/61494] -fsignaling-nans not taken into account for x - 0.0

[roger at nextmovesoftware dot com]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Roger Sayle  ---
Fixed.  Thanks Vincent.

[Bug rtl-optimization/61494] -fsignaling-nans not taken into account for x - 0.0

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

https://gcc.gnu.org/g:919c9d4bd3db7da09061af3b6f2a9193bf7bae45

commit r11-2502-g919c9d4bd3db7da09061af3b6f2a9193bf7bae45
Author: Roger Sayle 
Date:   Mon Aug 3 13:15:58 2020 +0100

PR rtl-optimization 61494: Preserve x-0.0 with HONOR_SNANS.

The following patch avoids simplifying x-0.0 to x when -fsignaling-nans
is specified, which resolves PR rtl-optimization 61494.  Indeed, running
the test program attached to that PR now reports no failures.

2020-08-02  Roger Sayle  

gcc/ChangeLog
PR rtl-optimization/61494
* simplify-rtx.c (simplify_binary_operation_1) [MINUS]: Don't
simplify x - 0.0 with -fsignaling-nans.

[Bug rtl-optimization/61494] -fsignaling-nans not taken into account for x - 0.0

[pangbw at gmail dot com]

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

baoshan  changed:

   What|Removed |Added

 CC||pangbw at gmail dot com

--- Comment #2 from baoshan  ---
Looking at the function simplify_binary_operation_1, I can see "!HONOR_SNANS
(mode)" has been added in a few places to prevent the incorrect transformation,
I believe to fix the issue we just add it to other places it should be there.

But the question is which place should we add this predication?
For case 1: "X - 0" to "X" we may say it is needed, but what about case 2:
"(X&C1)|C2" to "X|C2"? The quiet NaN would be generated but not in the original
location; if we think it is not needed I will think for the case 1 it is also
not needed because I believe the signaling 'X' would be used later and the
quite NaN would be generated eventually.
If we think for both of cases the predication is necessary, I would
think(suggest) every transformation in this function should be prohibited if
HONOR_SNANS (mode) is true.

[Bug rtl-optimization/61494] -fsignaling-nans not taken into account for x - 0.0

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-06-13
  Component|target  |rtl-optimization
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
RTL CSE optimizes x - 0.0 to x.  I thought it does nothing for FP ops ...

Confirmed.

static rtx
simplify_binary_operation_1 (enum rtx_code code, enum machine_mode mode,
 rtx op0, rtx op1, rtx trueop0, rtx trueop1)
{
...
case PLUS:
  /* Maybe simplify x + 0 to x.  The two expressions are equivalent
 when x is NaN, infinite, or finite and nonzero.  They aren't
 when x is -0 and the rounding mode is not towards -infinity,
 since (-0) + 0 is then 0.  */
  if (!HONOR_SIGNED_ZEROS (mode) && trueop1 == CONST0_RTX (mode))
return op0;
...
case MINUS:
  /* We can't assume x-x is 0 even with non-IEEE floating point,
 but since it is zero except in very strange circumstances, we
 will treat it as zero with -ffinite-math-only.  */
  if (rtx_equal_p (trueop0, trueop1)
  && ! side_effects_p (op0)
  && (!FLOAT_MODE_P (mode) || !HONOR_NANS (mode)))
return CONST0_RTX (mode);

  /* Change subtraction from zero into negation.  (0 - x) is the
 same as -x when x is NaN, infinite, or finite and nonzero.
 But if the mode has signed zeros, and does not round towards
 -infinity, then 0 - 0 is 0, not -0.  */
  if (!HONOR_SIGNED_ZEROS (mode) && trueop0 == CONST0_RTX (mode))
return simplify_gen_unary (NEG, mode, op1, mode);