[Bug c/108068] New: decimal signed zero is not honored

[Bug c/108068] New: decimal signed zero is not honored

[ntysdd at qq dot com]

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

            Bug ID: 108068
           Summary: decimal signed zero is not honored
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ntysdd at qq dot com
  Target Milestone: ---

This program has different behavior on different optimizing levels.

    #include <stdio.h>
    #include <decimal/decimal>

    int main()
    {
        std::decimal::decimal64 x;
        x = -1;
        while (x != 0)
        {
            x /= 10;
        }
        double d = decimal64_to_double(x);
        printf("%.0f\n", d);
    }


For example, on my current machine (gcc 9.4.0), it gives "-0" on O0, and "0" on
O1, then "-0" again on O2.

I believe it still has similar problems on 12.2

[Bug tree-optimization/108068] [10/11/12/13 Regression] decimal floating point signed zero is not honored

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Target Milestone|---                         |10.5
      Known to fail|                            |4.9.0, 6.1.0, 7.1.0, 8.1.0
            Summary|decimal signed zero is not  |[10/11/12/13 Regression]
                   |honored                     |decimal floating point
                   |                            |signed zero is not honored
      Known to work|                            |4.7.4, 4.8.1
          Component|middle-end                  |tree-optimization
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-12-12

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.
Introduced between 4.8 and 4.9. DOM is doing the 0.0 proping.

[Bug tree-optimization/108068] [10/11/12/13 Regression] decimal floating point signed zero is not honored

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jsm28 at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
           Priority|P3                          |P2

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Optimizing statement if (_5 != 0)

Visiting conditional with predicate: if (_5 != 0)

With known ranges
        _5: [unsupported_range] UNDEFINED

Predicate evaluates to: DON'T KNOW
LKUP STMT _5 ne_expr 0
0>>> COPY _5 = 0
<<<< COPY _5 = 0

the issue is we do

              bool can_infer_simple_equiv
                = !(HONOR_SIGNED_ZEROS (op1)
                    && (TREE_CODE (op1) == SSA_NAME || real_zerop (op1)));

but real_zerop is false for Decimal zero.  That's because "Trailing zeroes
matter for decimal float constants, so don't return 1 for them.".  We'd
need a real_maybe_zerop () for this usage.  We have other !real_zerop
checks in match.pd and elsewhere, those are susceptible as well.

Joseph, do you think adding DECIMAL_FLOAT_MODE_P checks in users is what
we want to do or do you think a real_nonzerop would be more appropriate
here?  I guess DOM want's to ask whether op1 may compare equal to zero.

[Bug tree-optimization/108068] [10/11/12/13 Regression] decimal floating point signed zero is not honored

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This was added for PR44683 and I bet the reason it uses real_zerop is that we
don't have other APIs, or at least ones that work on floating point types for
it.
I suppose short term we could use TREE_CODE (op0) == REAL_CST && TREE_REAL_CST
(op0).cl != rvc_zero but the question is what to do for COMPLEX_CSTs and
VECTOR_CSTs.
I bet for COMPLEX_CSTs, we shouldn't infer anything if signed zeros are allowed
and either real or imag or both parts are zero, for VECTOR_CSTs similarly if
any elt is zero.
For SSA_NAMEs eventually we could ask frange...

[Bug tree-optimization/108068] [10/11/12/13 Regression] decimal floating point signed zero is not honored

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 54144
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54144&action=edit
gcc13-pr108068.patch

Untested fix.

[Bug tree-optimization/108068] [10/11/12/13 Regression] decimal floating point signed zero is not honored

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
For DFP it's not just zero for which you can't infer an equivalence of 
values from an equality comparison; any finite value that can be 
represented with more than one quantum exponent (any value that can be 
represented with less precision than the type, unless it can only be 
represented with the largest or smallest possible quantum exponent) has 
the same property.  So handling DFP zero here probably isn't enough to 
avoid bugs.

[Bug tree-optimization/108068] [10/11/12/13 Regression] decimal floating point signed zero is not honored

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
And COMPLEX_CST shouldn't probably appear because cplxlower1 runs before dom2
and
VECTOR_CST because GIMPLE_CONDs need scalar conditions, not vector.
So maybe it is indeed enough to just punt on DECIMAL_FLOAT_TYPE_Ps.

[Bug tree-optimization/108068] [10/11/12/13 Regression] decimal floating point signed zero is not honored

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #6)
> And COMPLEX_CST shouldn't probably appear because cplxlower1 runs before
> dom2 and
> VECTOR_CST because GIMPLE_CONDs need scalar conditions, not vector.
> So maybe it is indeed enough to just punt on DECIMAL_FLOAT_TYPE_Ps.

We do allow equality compares of whole vectors, so vectors still can
appear.

[Bug tree-optimization/108068] [10/11/12/13 Regression] decimal floating point signed zero is not honored

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 54146
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54146&action=edit
gcc13-pr108068.patch

Overnight I've successfully bootstrapped/regtested this, but given your comment
that might not be good enough.

[Bug tree-optimization/108068] [10/11/12/13 Regression] decimal floating point signed zero is not honored

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 54147
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54147&action=edit
gcc13-pr108068.patch

So like this instead?  Untested so far.

[Bug tree-optimization/108068] [10/11/12/13 Regression] decimal floating point signed zero is not honored

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 22 Dec 2022, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108068
> 
> --- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Created attachment 54147
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54147&action=edit
> gcc13-pr108068.patch
> 
> So like this instead?  Untested so far.

LGTM.

[Bug tree-optimization/108068] [10/11/12/13 Regression] decimal floating point signed zero is not honored

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 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:fd1b0aefda5b65f3f841ca6e61ccea6a72daa060

commit r13-4877-gfd1b0aefda5b65f3f841ca6e61ccea6a72daa060
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Dec 23 16:12:21 2022 +0100

    tree-ssa-dom: can_infer_simple_equiv fixes [PR108068]

    As reported in the PR, tree-ssa-dom.cc uses real_zerop call to find
    if a floating point constant is zero and it shouldn't try to infer
    equivalences from comparison against it if signed zeros are honored.
    This doesn't work at all for decimal types, because real_zerop always
    returns false for them (one can have different representations of decimal
    zero beyond -0/+0), and it doesn't work for vector compares either,
    as real_zerop checks if all elements are zero, while we need to avoid
    infering equivalences from comparison against vector constants which have
    at least one zero element in it (if signed zeros are honored).
    Furthermore, as mentioned by Joseph, for decimal types many other values
    aren't singleton.

    So, this patch stops infering anything if element mode is decimal, and
    otherwise uses instead of real_zerop a new function, real_maybe_zerop,
    which will work even for decimal types and for complex or vector will
    return true if any element is or might be zero (so it returns true
    for anything but constants for now).

    2022-12-23  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/108068
            * tree.h (real_maybe_zerop): Declare.
            * tree.cc (real_maybe_zerop): Define.
            * tree-ssa-dom.cc (record_edge_info): Use it instead of
            real_zerop or TREE_CODE (op1) == SSA_NAME || real_zerop.  Always
set
            can_infer_simple_equiv to false for decimal floating point types.

            * gcc.dg/dfp/pr108068.c: New test.

[Bug tree-optimization/108068] [10/11/12 Regression] decimal floating point signed zero is not honored

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[10/11/12/13 Regression]    |[10/11/12 Regression]
                   |decimal floating point      |decimal floating point
                   |signed zero is not honored  |signed zero is not honored

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk for now.

[Bug tree-optimization/108068] [10/11/12 Regression] decimal floating point signed zero is not honored

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:29ac1dcd36901a094f7d698bbe244489a58e2715

commit r12-9134-g29ac1dcd36901a094f7d698bbe244489a58e2715
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Dec 23 16:12:21 2022 +0100

    tree-ssa-dom: can_infer_simple_equiv fixes [PR108068]

    As reported in the PR, tree-ssa-dom.cc uses real_zerop call to find
    if a floating point constant is zero and it shouldn't try to infer
    equivalences from comparison against it if signed zeros are honored.
    This doesn't work at all for decimal types, because real_zerop always
    returns false for them (one can have different representations of decimal
    zero beyond -0/+0), and it doesn't work for vector compares either,
    as real_zerop checks if all elements are zero, while we need to avoid
    infering equivalences from comparison against vector constants which have
    at least one zero element in it (if signed zeros are honored).
    Furthermore, as mentioned by Joseph, for decimal types many other values
    aren't singleton.

    So, this patch stops infering anything if element mode is decimal, and
    otherwise uses instead of real_zerop a new function, real_maybe_zerop,
    which will work even for decimal types and for complex or vector will
    return true if any element is or might be zero (so it returns true
    for anything but constants for now).

    2022-12-23  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/108068
            * tree.h (real_maybe_zerop): Declare.
            * tree.cc (real_maybe_zerop): Define.
            * tree-ssa-dom.cc (record_edge_info): Use it instead of
            real_zerop or TREE_CODE (op1) == SSA_NAME || real_zerop.  Always
set
            can_infer_simple_equiv to false for decimal floating point types.

            * gcc.dg/dfp/pr108068.c: New test.

    (cherry picked from commit fd1b0aefda5b65f3f841ca6e61ccea6a72daa060)

[Bug tree-optimization/108068] [10/11 Regression] decimal floating point signed zero is not honored

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[10/11/12 Regression]       |[10/11 Regression] decimal
                   |decimal floating point      |floating point signed zero
                   |signed zero is not honored  |is not honored

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for gcc 12.3 too.

[Bug tree-optimization/108068] [10/11 Regression] decimal floating point signed zero is not honored

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-10695-gd8f95474581843c605bb97ba83d482d642da3a1b
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Dec 23 16:12:21 2022 +0100

    tree-ssa-dom: can_infer_simple_equiv fixes [PR108068]

    As reported in the PR, tree-ssa-dom.cc uses real_zerop call to find
    if a floating point constant is zero and it shouldn't try to infer
    equivalences from comparison against it if signed zeros are honored.
    This doesn't work at all for decimal types, because real_zerop always
    returns false for them (one can have different representations of decimal
    zero beyond -0/+0), and it doesn't work for vector compares either,
    as real_zerop checks if all elements are zero, while we need to avoid
    infering equivalences from comparison against vector constants which have
    at least one zero element in it (if signed zeros are honored).
    Furthermore, as mentioned by Joseph, for decimal types many other values
    aren't singleton.

    So, this patch stops infering anything if element mode is decimal, and
    otherwise uses instead of real_zerop a new function, real_maybe_zerop,
    which will work even for decimal types and for complex or vector will
    return true if any element is or might be zero (so it returns true
    for anything but constants for now).

    2022-12-23  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/108068
            * tree.h (real_maybe_zerop): Declare.
            * tree.c (real_maybe_zerop): Define.
            * tree-ssa-dom.c (record_edge_info): Use it instead of
            real_zerop or TREE_CODE (op1) == SSA_NAME || real_zerop.  Always
set
            can_infer_simple_equiv to false for decimal floating point types.

            * gcc.dg/dfp/pr108068.c: New test.

    (cherry picked from commit fd1b0aefda5b65f3f841ca6e61ccea6a72daa060)

[Bug tree-optimization/108068] [10 Regression] decimal floating point signed zero is not honored

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[10/11 Regression] decimal  |[10 Regression] decimal
                   |floating point signed zero  |floating point signed zero
                   |is not honored              |is not honored

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 11.4 as well.

[Bug tree-optimization/108068] [10 Regression] decimal floating point signed zero is not honored

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-11353-gfc8c0f806728692b24fe57849ca4e1f70d882e92
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Dec 23 16:12:21 2022 +0100

    tree-ssa-dom: can_infer_simple_equiv fixes [PR108068]

    As reported in the PR, tree-ssa-dom.cc uses real_zerop call to find
    if a floating point constant is zero and it shouldn't try to infer
    equivalences from comparison against it if signed zeros are honored.
    This doesn't work at all for decimal types, because real_zerop always
    returns false for them (one can have different representations of decimal
    zero beyond -0/+0), and it doesn't work for vector compares either,
    as real_zerop checks if all elements are zero, while we need to avoid
    infering equivalences from comparison against vector constants which have
    at least one zero element in it (if signed zeros are honored).
    Furthermore, as mentioned by Joseph, for decimal types many other values
    aren't singleton.

    So, this patch stops infering anything if element mode is decimal, and
    otherwise uses instead of real_zerop a new function, real_maybe_zerop,
    which will work even for decimal types and for complex or vector will
    return true if any element is or might be zero (so it returns true
    for anything but constants for now).

    2022-12-23  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/108068
            * tree.h (real_maybe_zerop): Declare.
            * tree.c (real_maybe_zerop): Define.
            * tree-ssa-dom.c (record_edge_info): Use it instead of
            real_zerop or TREE_CODE (op1) == SSA_NAME || real_zerop.  Always
set
            can_infer_simple_equiv to false for decimal floating point types.

            * gcc.dg/dfp/pr108068.c: New test.

    (cherry picked from commit fd1b0aefda5b65f3f841ca6e61ccea6a72daa060)

[Bug tree-optimization/108068] [10 Regression] decimal floating point signed zero is not honored

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 10.5 too.