[Bug target/95115] New: [10 Regression] RISC-V 64: inf/inf division optimized out, invalid operation not raised

[Bug target/95115] New: [10 Regression] RISC-V 64: inf/inf division optimized out, invalid operation not raised

[aurelien at aurel32 dot net]

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

            Bug ID: 95115
           Summary: [10 Regression] RISC-V 64: inf/inf division optimized
                    out, invalid operation not raised
           Product: gcc
           Version: 10.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: aurelien at aurel32 dot net
  Target Milestone: ---
              Host: riscv64-unknown-linux-gnu
            Target: riscv64-unknown-linux-gnu
             Build: riscv64-unknown-linux-gnu

Created attachment 48525
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48525&action=edit
Testcase

On 64-bit RISC-V, the acos/asin tests from the glibc testsuite fails when it is
built with GCC 10, as the invalid operation flag is not raised for invalid
input values. The glibc code uses the following code to generate a NaN and
raise an invalid input [1]:

  else {
    u.i[HIGH_HALF]=0x7ff00000;
    v.i[HIGH_HALF]=0x7ff00000;
    u.i[LOW_HALF]=0;
    v.i[LOW_HALF]=0;
    return u.x/v.x;
  }

With GCC 9, this results in the following code:
        li      a1,2047
        slli    a1,a1,52
        fmv.d.x fa5,a1
        li      a0,16
        fdiv.d  fs0,fa5,fa5

With GCC 10, the division is optimized out and the result is directly loaded as
a constant, causing the invalid operation not to be raised.

I have attached a small testcase to reproduce the issue.

[Bug target/95115] [10 Regression] RISC-V 64: inf/inf division optimized out, invalid operation not raised

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse <glisse at gcc dot gnu.org> ---
I am seeing the same thing on x86_64, happens during FRE1, so it looks like
tree-optimization.

[Bug target/95115] [10 Regression] RISC-V 64: inf/inf division optimized out, invalid operation not raised

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse <glisse at gcc dot gnu.org> ---
Or during CCP with the simpler

double f(){
  double d=__builtin_inf();
  return d/d;
}

and all the -frounding-math -ftrapping-math -fsignaling-nans don't seem to
help.

[Bug target/95115] [10 Regression] RISC-V 64: inf/inf division optimized out, invalid operation not raised

[wilson at gcc dot gnu.org]

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

Jim Wilson <wilson at gcc dot gnu.org> changed:

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

--- Comment #3 from Jim Wilson <wilson at gcc dot gnu.org> ---
Marc Glisse's testcase fails even with old gcc versions.  My x86_64 Ubuntu
16.04 gcc-5.4.0 also removes the divide with -O.  My Ubuntu 18.04 gcc-7.5.0
gives the same result.  This seems to be simple constant folding that we have
always done.  The assumption here seems to be that if the user is dividing
constants, then we don't need to worry about setting exception bits.  If I
write (4.0 / 3.0) for instance, the compiler just folds it and doesn't worry
about setting the inexact bit.

Aurelien Jarno's testcase in the attachment is more interesting, as that works
with older gcc versions, just not gcc-10.  I did a bisect, and tracked this
down to the Richard Biener's patch for pr83518.  It looks like the glibc code
was obfuscated a bit to try to avoid the usual trivial constant folding, and
the patch for pr83518 just made gcc smart enough to recognize that constants
are involved, and then optimize this case the same way we have always optimized
FP constant divides.

Newlib incidentally uses (x-x)/(x-x) where x is the input value, so there are
no constants involved, and the divide does not get optimized away.  This still
works with gcc-10.  The result is a subtract followed by a divide.

At first glance, this looks more like a glibc problem to me than a gcc problem.
 But maybe the fact that constants were written to memory and then read back in
should prevent the usual trivial FP constant divide folding.

I can almost make the glibc testcase work if I mark the unions as volatile. 
That prevents the union reads and writes from being optimized away, but the
divide gets moved after the fetestexcept call.  That looks like a gcc bug
though I think a different problem that this pr.  The 234t.optimized dump is
correct.  The 236r.expand dump is wrong.  This happens for both x86_64 and
RISC-V.  The resulting code is bigger than what the newlib trick generates
though.

[Bug target/95115] [10 Regression] RISC-V 64: inf/inf division optimized out, invalid operation not raised

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Jim Wilson from comment #3)
> The assumption here seems to be that if the user is
> dividing constants, then we don't need to worry about setting exception
> bits.  If I write (4.0 / 3.0) for instance, the compiler just folds it and
> doesn't worry about setting the inexact bit.

We don't fold 0./0. though (unless -fno-trapping-math), it would make sense for
Inf/Inf to behave the same. And -frounding-math protects 4./3.

> divide gets moved after the fetestexcept call.  That looks like a gcc bug

Yes, that one is known.

[Bug target/95115] [10 Regression] RISC-V 64: inf/inf division optimized out, invalid operation not raised

[aurelien at aurel32 dot net]

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

--- Comment #5 from Aurelien Jarno <aurelien at aurel32 dot net> ---
(In reply to Jim Wilson from comment #3)
> Newlib incidentally uses (x-x)/(x-x) where x is the input value, so there
> are no constants involved, and the divide does not get optimized away.  This
> still works with gcc-10.  The result is a subtract followed by a divide.

This is also what is used for acosf and asinf, that's why the problem only
appears with the double variant.

[Bug middle-end/95115] RISC-V 64: inf/inf division optimized out, invalid operation not raised

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Target|riscv64-unknown-linux-gnu   |
            Summary|[10 Regression] RISC-V 64:  |RISC-V 64: inf/inf division
                   |inf/inf division optimized  |optimized out, invalid
                   |out, invalid operation not  |operation not raised
                   |raised                      |
   Last reconfirmed|                            |2020-05-14
     Ever confirmed|0                           |1
          Component|target                      |middle-end
              Build|riscv64-unknown-linux-gnu   |
               Host|riscv64-unknown-linux-gnu   |
             Status|UNCONFIRMED                 |NEW

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(simplify
 (rdiv @0 @0)
 (if (FLOAT_TYPE_P (type)
      && ! HONOR_NANS (type)
      && ! HONOR_INFINITIES (type))
  { build_one_cst (type); }))

so that's not it, possibly constant folding instead in const_binop.
There we only have

1276          /* Don't perform operation if we honor signaling NaNs and
1277             either operand is a signaling NaN.  */
1278          if (HONOR_SNANS (mode)
1279              && (REAL_VALUE_ISSIGNALING_NAN (d1)
1280                  || REAL_VALUE_ISSIGNALING_NAN (d2)))
1281            return NULL_TREE;

and

1283          /* Don't perform operation if it would raise a division
(gdb) 
1284             by zero exception.  */
1285          if (code == RDIV_EXPR
1286              && real_equal (&d2, &dconst0)
1287              && (flag_trapping_math || ! MODE_HAS_INFINITIES (mode)))
1288            return NULL_TREE;

which both don't trigger.  Afterwards

1309          inexact = real_arithmetic (&value, code, &d1, &d2);

even returns false and the result is a qNaN.

For the specific regression in this bug we now simply are able to
turn

    return u.x/v.x;

into a division of two constants.  That's nothing we're going to "fix",
so we have to fix the above instead which is a much older issue.

[Bug middle-end/95115] RISC-V 64: inf/inf division optimized out, invalid operation not raised

[vgupta at synopsys dot com]

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

Vineet Gupta <vgupta at synopsys dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |claziss at gmail dot com,
                   |                            |vgupta at synopsys dot com

--- Comment #7 from Vineet Gupta <vgupta at synopsys dot com> ---
FWIW this is also applicable to ARC glibc + upstream gcc 10

https://sourceware.org/pipermail/libc-alpha/2020-July/115679.html
https://sourceware.org/pipermail/libc-alpha/2020-July/115694.html

[Bug middle-end/95115] RISC-V 64: inf/inf division optimized out, invalid operation not raised

[xry111 at mengyan1223 dot wang]

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

--- Comment #8 from Xi Ruoyao <xry111 at mengyan1223 dot wang> ---
This is causing Glibc test failure on every port without hardware acos/asin
instruction.

[Bug middle-end/95115] RISC-V 64: inf/inf division optimized out, invalid operation not raised

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Xi Ruoyao <xry111@gcc.gnu.org>:

https://gcc.gnu.org/g:34afa19d29c5bf0b0f504e4d0aca4e9a8bc82c5c

commit r12-6959-g34afa19d29c5bf0b0f504e4d0aca4e9a8bc82c5c
Author: Xi Ruoyao <xry111@mengyan1223.wang>
Date:   Mon Jan 31 01:15:20 2022 +0800

    fold-const: do not fold NaN result from non-NaN operands [PR95115]

    These operations should raise an invalid operation exception at runtime.
    So they should not be folded during compilation unless -fno-trapping-math
    is used.

    gcc/
            PR middle-end/95115
            * fold-const.cc (const_binop): Do not fold NaN result from
              non-NaN operands.

    gcc/testsuite
            * gcc.dg/pr95115.c: New test.

[Bug middle-end/95115] RISC-V 64: inf/inf division optimized out, invalid operation not raised

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Xi Ruoyao <xry111@gcc.gnu.org>:

https://gcc.gnu.org/g:8799006ab889b8bd8a6d6fbea5ddb64a17b2e541

commit r11-9531-g8799006ab889b8bd8a6d6fbea5ddb64a17b2e541
Author: Xi Ruoyao <xry111@mengyan1223.wang>
Date:   Mon Jan 31 01:15:20 2022 +0800

    fold-const: do not fold NaN result from non-NaN operands [PR95115]

    These operations should raise an invalid operation exception at runtime.
    So they should not be folded during compilation unless -fno-trapping-math
    is used.

    gcc/
            PR middle-end/95115
            * fold-const.c (const_binop): Do not fold NaN result from
              non-NaN operands.

    gcc/testsuite
            * gcc.dg/pr95115.c: New test.

    (cherry picked from commit 34afa19d29c5bf0b0f504e4d0aca4e9a8bc82c5c)

[Bug middle-end/95115] RISC-V 64: inf/inf division optimized out, invalid operation not raised

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Xi Ruoyao <xry111@gcc.gnu.org>:

https://gcc.gnu.org/g:9c9494533a78df07f2b32097fe1e78f68369dc94

commit r10-10432-g9c9494533a78df07f2b32097fe1e78f68369dc94
Author: Xi Ruoyao <xry111@mengyan1223.wang>
Date:   Mon Jan 31 01:15:20 2022 +0800

    fold-const: do not fold NaN result from non-NaN operands [PR95115]

    These operations should raise an invalid operation exception at runtime.
    So they should not be folded during compilation unless -fno-trapping-math
    is used.

    gcc/
            PR middle-end/95115
            * fold-const.c (const_binop): Do not fold NaN result from
              non-NaN operands.

    gcc/testsuite
            * gcc.dg/pr95115.c: New test.

    (cherry picked from commit 34afa19d29c5bf0b0f504e4d0aca4e9a8bc82c5c)

[Bug middle-end/95115] RISC-V 64: inf/inf division optimized out, invalid operation not raised

[xry111 at mengyan1223 dot wang]

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

--- Comment #12 from Xi Ruoyao <xry111 at mengyan1223 dot wang> ---
Should be fixed in trunk, and gcc-10 & 11 branch.

[Bug middle-end/95115] RISC-V 64: inf/inf division optimized out, invalid operation not raised

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.4
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED
      Known to work|                            |10.3.1, 11.2.1, 12.0

--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed so closing.