[Bug web/111694] New: Wrong behavior for signbit of negative zero when optimizing

[Bug web/111694] New: Wrong behavior for signbit of negative zero when optimizing

[alonzakai at gmail dot com]

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

            Bug ID: 111694
           Summary: Wrong behavior for signbit of negative zero when
                    optimizing
           Product: gcc
           Version: 13.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: web
          Assignee: unassigned at gcc dot gnu.org
          Reporter: alonzakai at gmail dot com
  Target Milestone: ---

This behaves incorrectly in 13.2.0 with -O1 and above, but is correct in 12,
11, and 10. It is also correct in 13.2.0 without optimizations.

Testcase:


#include <math.h>
#include <stdio.h>

void test(double l, double r) {
  if (l == r && l == 0 && (signbit(l) || signbit(r))) {
    puts("one is negative");
  }
}

int main() {
  test(0.0, -0.0);
  test(-0.0, 0.0);
}


This should print "one is negative" twice, but only does so once in 13.2.0 with
-O1:

$ gcc-13 a.c -O1 ; ./a.out
one is negative
$ gcc-13 a.c -O0 ; ./a.out
one is negative
one is negative
$

[Bug tree-optimization/111694] [13/14 Regression] Wrong behavior for signbit of negative zero when optimizing

[amonakov at gcc dot gnu.org]

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

Alexander Monakov <amonakov at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amonakov at gcc dot gnu.org
          Component|web                         |tree-optimization
            Summary|Wrong behavior for signbit  |[13/14 Regression] Wrong
                   |of negative zero when       |behavior for signbit of
                   |optimizing                  |negative zero when
                   |                            |optimizing
           Keywords|                            |wrong-code

--- Comment #1 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
Reduced:

#define signbit(x) __builtin_signbit(x)

static void test(double l, double r)
{
  if (l == r && (signbit(l) || signbit(r)))
    ;
  else
    __builtin_abort();
}

int main()
{
  test(0.0, -0.0);
}

[Bug tree-optimization/111694] [13/14 Regression] Wrong behavior for signbit of negative zero when optimizing

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.3
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-10-04
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed. 


EVRP removes the second __bultin_signbit incorrectly.
Most likely due to:
```

Folding statement: if (_3 != 0)
 Registering value_relation (l_11(D) == r_12(D)) on (2->3)
```

which then we get:
```
Predicate evaluates to: DON'T KNOW
Matching expression match.pd:2679, gimple-match-2.cc:35
Matching expression match.pd:2682, gimple-match-1.cc:66
Matching expression match.pd:2689, gimple-match-2.cc:96
Not folded
Folding statement: _20 = __builtin_signbit (r_12(D));
Queued stmt for removal.  Folds to: 0
Folding statement: if (_20 != 0)
gimple_simplified to if (0 != 0)
gimple_simplified to if (0 != 0)
Folded into: if (0 != 0)
```

For -O1 DOM does:
```
1>>> STMT 1 = _8 le_expr 0
1>>> STMT 1 = _8 ge_expr 0
1>>> STMT 1 = _8 eq_expr 0
1>>> STMT 0 = _8 ne_expr 0
0>>> COPY _8 = 0
Optimizing statement _10 = __builtin_signbit (r_6(D));
  Replaced 'r_6(D)' with constant '0.0'
gimple_simplified to _10 = 0;
  Folded to: _10 = 0;
LKUP STMT _10 = 0
==== ASGN _10 = 0
Optimizing statement if (_10 != 0)
  Replaced '_10' with constant '0'
gimple_simplified to if (0 != 0)
  Folded to: if (0 != 0)
LKUP STMT 0 ne_expr 0
<<<< STMT 0 = _8 ne_expr 0
<<<< STMT 1 = _8 eq_expr 0
<<<< STMT 1 = _8 ge_expr 0
<<<< STMT 1 = _8 le_expr 0
<<<< COPY _8 = 0
```
Which is wrong too.

[Bug tree-optimization/111694] [13/14 Regression] Wrong behavior for signbit of negative zero when optimizing

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu.org,
                   |                            |amacleod at redhat dot com
           Priority|P3                          |P2
      Known to work|                            |12.3.0

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Looks like some frange / relation mistake then.

[Bug tree-optimization/111694] [13/14 Regression] Wrong behavior for signbit of negative zero when optimizing

[amacleod at redhat dot com]

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

--- Comment #4 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Richard Biener from comment #3)
> Looks like some frange / relation mistake then.


l_3(D)  [frange] double [-Inf, +Inf]
Equivalence set : [l_3(D), r_4(D)]
    <bb 3> :
    _1 = __builtin_signbit (l_3(D));
    if (_1 != 0)
      goto <bb 6>; [INV]
    else
      goto <bb 4>; [INV]

3->6  (T) _1 :  [irange] int [-INF, -1][1, +INF]
3->6  (T) l_3(D) :      [frange] double [-Inf, -0.0 (-0x0.0p+0)]
3->4  (F) _1 :  [irange] int [0, 0]
3->4  (F) l_3(D) :      [frange] double [0.0 (0x0.0p+0), +Inf]

    <bb 4> :
    _2 = __builtin_signbit (r_4(D));

Yeah, we know l_3 and r_4 are equivalent, and we also know that on the edge
3->4 l_3 has the range  double [0.0 (0x0.0p+0), +Inf]

When we miss is that with an equivalence, we also have to put -0.0 back into
the range.  We currently don't so we think we can fold the second signbit call.

If I fix that, we then see 
r_4(D)  [frange] double [-0.0 (-0x0.0p+0), +Inf]
which prevents the folding.  

I need to audit to see if there are other places where we may have to "adjust"
equivalence range, or how best to deal with this in the general case.

[Bug tree-optimization/111694] [13/14 Regression] Wrong behavior for signbit of negative zero when optimizing

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrew Macleod <amacleod@gcc.gnu.org>:

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

commit r14-4520-gb0892b1fc637fadf14d7016858983bc5776a1e69
Author: Andrew MacLeod <amacleod@redhat.com>
Date:   Mon Oct 9 10:15:07 2023 -0400

    Ensure float equivalences include + and - zero.

    A floating point equivalence may not properly reflect both signs of
    zero, so be pessimsitic and ensure both signs are included.

            PR tree-optimization/111694
            gcc/
            * gimple-range-cache.cc (ranger_cache::fill_block_cache): Adjust
            equivalence range.
            * value-relation.cc (adjust_equivalence_range): New.
            * value-relation.h (adjust_equivalence_range): New prototype.

            gcc/testsuite/
            * gcc.dg/pr111694.c: New.

[Bug tree-optimization/111694] [13/14 Regression] Wrong behavior for signbit of negative zero when optimizing

[amacleod at redhat dot com]

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

Andrew Macleod <amacleod at redhat dot com> changed:

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

--- Comment #6 from Andrew Macleod <amacleod at redhat dot com> ---
fixed

[Bug tree-optimization/111694] [13/14 Regression] Wrong behavior for signbit of negative zero when optimizing

[amonakov at gcc dot gnu.org]

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

--- Comment #7 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
No backport for gcc-13 planned?

[Bug tree-optimization/111694] [13/14 Regression] Wrong behavior for signbit of negative zero when optimizing

[amacleod at redhat dot com]

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

Andrew Macleod <amacleod at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |---
             Status|RESOLVED                    |REOPENED

--- Comment #8 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Alexander Monakov from comment #7)
> No backport for gcc-13 planned?

mmm, didn't realize were we propagating floating point equivalences around in
13.  similar patch should work there

[Bug tree-optimization/111694] [13/14 Regression] Wrong behavior for signbit of negative zero when optimizing

[amacleod at redhat dot com]

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

--- Comment #9 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Andrew Macleod from comment #8)
> (In reply to Alexander Monakov from comment #7)
> > No backport for gcc-13 planned?
> 
> mmm, didn't realize were we propagating floating point equivalences around
> in 13.  similar patch should work there

Testing same patch on gcc13. will let it settle on trunk for a day or two
first, then check it in if nothing shows up.    which it shouldn't :-)

[Bug tree-optimization/111694] [13/14 Regression] Wrong behavior for signbit of negative zero when optimizing

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Andrew Macleod
<amacleod@gcc.gnu.org>:

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

commit r13-7945-gf0efc4b25cba1bd35b08b7dfbab0f8fc81b55c66
Author: Andrew MacLeod <amacleod@redhat.com>
Date:   Mon Oct 9 13:40:15 2023 -0400

    Ensure float equivalences include + and - zero.

    A floating point equivalence may not properly reflect both signs of
    zero, so be pessimsitic and ensure both signs are included.

            PR tree-optimization/111694
            gcc/
            * gimple-range-cache.cc (ranger_cache::fill_block_cache): Adjust
            equivalence range.
            * value-relation.cc (adjust_equivalence_range): New.
            * value-relation.h (adjust_equivalence_range): New prototype.

            gcc/testsuite/
            * gcc.dg/pr111694.c: New.

[Bug tree-optimization/111694] [13/14 Regression] Wrong behavior for signbit of negative zero when optimizing

[amacleod at redhat dot com]

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

Andrew Macleod <amacleod at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #11 from Andrew Macleod <amacleod at redhat dot com> ---
now fixed on gcc 13 too.