[Bug target/61441] New: ARM aarch64 fails to quiet signaling NaN

[Bug target/61441] New: ARM aarch64 fails to quiet signaling NaN

[aurelien at aurel32 dot net]

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

            Bug ID: 61441
           Summary: ARM aarch64 fails to quiet signaling NaN
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: aurelien at aurel32 dot net
              Host: aarch64-unknown-linux-gnu
            Target: aarch64-unknown-linux-gnu
             Build: aarch64-unknown-linux-gnu

Consider the following code:

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

int main (void)
{
  float sNaN = __builtin_nansf ("");
  double x = (double) sNaN;
  return issignaling(x);
}

It correctly returns 0 at -O0 optimisation level, but returns 1 at -O1 and -O2
optimisation levels.

Here is the generated assembly code at -O0:
0000000000400630 <main>:
  400630:       a9be7bfd        stp     x29, x30, [sp,#-32]!
  400634:       910003fd        mov     x29, sp
  400638:       18000160        ldr     w0, 400664 <main+0x34>
  40063c:       b9001fa0        str     w0, [x29,#28]
  400640:       b9401fa0        ldr     w0, [x29,#28]
  400644:       1e270000        fmov    s0, w0
  400648:       1e22c000        fcvt    d0, s0
  40064c:       9e660000        fmov    x0, d0
  400650:       f9000ba0        str     x0, [x29,#16]
  400654:       fd400ba0        ldr     d0, [x29,#16]
  400658:       97ffff8e        bl      400490 <__issignaling@plt>
  40065c:       a8c27bfd        ldp     x29, x30, [sp],#32
  400660:       d65f03c0        ret
  400664:       7fa00000        .word   0x7fa00000

Here is the generated assembly code at -O1:
0000000000400630 <main>:
  400630:       a9bf7bfd        stp     x29, x30, [sp,#-16]!
  400634:       910003fd        mov     x29, sp
  400638:       5c000080        ldr     d0, 400648 <main+0x18>
  40063c:       97ffff95        bl      400490 <__issignaling@plt>
  400640:       a8c17bfd        ldp     x29, x30, [sp],#16
  400644:       d65f03c0        ret
  400648:       00000000        .word   0x00000000
  40064c:       7ff40000        .word   0x7ff40000

As you can see at -O1, the sNaN constant is propagated, and the propagated
value is loaded and passed directly to issignaling. Quoting the IEEE Std 754
standard:
"Under default exception handling, any operation signaling an invalid operation
exception and for which a floating-point result is to be delivered shall
deliver a quiet NaN."

So it looks like the copy propagation is not done correctly, the sNaN should be
silenced in the process.

[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ramana at gcc dot gnu.org
          Component|target                      |tree-optimization

--- Comment #1 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
I see the same behaviour on x86_64-linux-gnu , there is nothing specific about
this behaviour with respect to the AArch64 port. 

I can see this is ccp that causes the propagation in the brief time I looked at
it. What I haven't yet done is audit the options bits to work out what the
issues here.

[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN

[ssaraswati at gmail dot com]

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

Sujoy <ssaraswati at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ssaraswati at gmail dot com

--- Comment #2 from Sujoy <ssaraswati at gmail dot com> ---
I could reproduce this on x86_64-linux-gnu with 4.9 and trunk.

As far as the issue is concerned, the ccp propagates the sNaN value at -O1 or
higher optimization level. Should this be done only when -fsignaling-nans is
on? From the man page of gcc, -fsignaling-nans says -

"Compile code assuming that IEEE signaling NaNs may generate user-visible traps
during floating-point operations.  Setting this option disables optimizations
that may change the number of exceptions visible with signaling NaNs."

Going by this, should we stop ccp from folding sNaN values when
-fsignaling-nans is on? However, the man page also says the following for
-fsignaling-nans -

"This option is experimental and does not currently guarantee to disable all
GCC optimizations that affect signaling NaN behavior."

Given this, may be we can probably let ccp propagate the sNaN value if
-fsignaling-nans is on, and change it to qNaN otherwise. With this though, we
would still see different behavior for the test case at -O0 and -O1 when
-fsignaling-nans is used.

Is my understanding right? I would be interested in pushing a patch for this if
this issue is confirmed. What would be the process to get this confirmed?

[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
Bugs in -fsignaling-nans (in this case, that a conversion of a signaling 
NaN from float to double is incorrectly folded) should be fixed just like 
any other bug.  That sentence is simply warning that there are many known 
bugs in this area.

[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN

[ssaraswati at gmail dot com]

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

--- Comment #4 from Sujoy <ssaraswati at gmail dot com> ---
Yes, I agree to your comment.

With -fno-signaling-nans (which is the default), we need to fix the ccp so that
the sNaN is converted to qNaN when the value is propagated.

With -fsignaling-nans, we need to ensure that we disable the folding since it
reduces the number of exceptions visible with sNaNs. I notice that even if I
disable ccp, other optimizations like dead code elimination with cddce also
needs to be disabled. Let me know if you agree.

[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Thu, 13 Aug 2015, ssaraswati at gmail dot com wrote:

> With -fno-signaling-nans (which is the default), we need to fix the ccp so that
> the sNaN is converted to qNaN when the value is propagated.

With -fno-signaling-nans we don't really care about the result value.

> With -fsignaling-nans, we need to ensure that we disable the folding since it
> reduces the number of exceptions visible with sNaNs. I notice that even if I

More precisely, exceptions are relevant with -fsignaling-nans 
-ftrapping-math but even with -fno-trapping-math it's still visible if the 
result is wrongly a sNaN instead of a qNaN.  (-ftrapping-math is the 
default.  It's not clear there's any use for -fsignaling-nans 
-fno-trapping-math.  But -fsignaling-nans is the option that says there 
may be signaling NaN arguments, and -ftrapping-math is the option that 
says we care about exceptions.)

The *number* of exceptions isn't relevant, only the set raised at any 
point (e.g. function call) where the raised exceptions may be tested or 
modified; it's valid to change one nonzero number of times raising a given 
exception between two such points to a different nonzero number of times 
raising that exception.

> disable ccp, other optimizations like dead code elimination with cddce also
> needs to be disabled. Let me know if you agree.

I'm sure there are lots of optimizations that wrongly discard exceptions, 
whether for signaling NaNs or other operands.

Roughly, the present -ftrapping-math seems to be implemented as meaning 
that an expression shouldn't be transformed to change the exceptions 
raised, but exceptions aren't treated as side effects so it can still be 
discarded if apparently unused, or moved past code that might test or 
modify exceptions.  Something stricter that actually follows Annex F would 
treat exceptions more like side effects and eliminate a lot of code 
movement / dead code removal.  It might be less suitable for the default 
compilation mode, however.

I expect there are plenty of bugs even with that more limited description 
of what -ftrapping-math tries to do.

[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN

[ssaraswati at gmail dot com]

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

--- Comment #6 from Sujoy <ssaraswati at gmail dot com> ---
(In reply to joseph@codesourcery.com from comment #5)

> With -fno-signaling-nans we don't really care about the result value.

I am not sure about this. -fno-signaling-nans is default and the original issue
mentions that "under default exception handling, any operation signaling an
invalid operation exception and for which a floating-point result is to be
delivered shall deliver a quiet NaN". If we have to honor the default exception
handling case, we need to convert the sNaN to qNaN here. Let me know if I
missed something.

> More precisely, exceptions are relevant with -fsignaling-nans 
> -ftrapping-math but even with -fno-trapping-math it's still visible if the 
> result is wrongly a sNaN instead of a qNaN.  (-ftrapping-math is the 
> default.  It's not clear there's any use for -fsignaling-nans 
> -fno-trapping-math.  But -fsignaling-nans is the option that says there 
> may be signaling NaN arguments, and -ftrapping-math is the option that 
> says we care about exceptions.)

The man page entry for -fno-trapping-math says 
"This option requires that -fno-signaling-nans be in effect." 

The description for -fsignaling-nans says
"This option implies -ftrapping-math."

Hence, only the following combinations should be valid -
1) -fno-trapping-math and -fno-signaling-nans
2) -ftrapping-math and -fno-signaling-nans (default)
3) -ftrapping-math and -fsignaling-nans

Here is my understanding -

For case 1, we can go ahead with optimizations that may remove operations that
may lead to exceptions, as we don't care about them. Also, we convert sNaN to
qNaN since -fno-signaling-nans is on.

For case 2, we can do the transformation like folding and they should convert
sNaN to qNaN since -fno-signaling-nans is on.

For case 3, we have to disallow certain transformation so that any operation
leading to exception due to sNaN is not optimized away.

> The *number* of exceptions isn't relevant, only the set raised at any 
> point (e.g. function call) where the raised exceptions may be tested or 
> modified; it's valid to change one nonzero number of times raising a given 
> exception between two such points to a different nonzero number of times 
> raising that exception.

Thanks for this information. Does this mean that the man page description of
-fsignaling-nans is too restrictive? 

> I'm sure there are lots of optimizations that wrongly discard exceptions, 
> whether for signaling NaNs or other operands.
> 
> Roughly, the present -ftrapping-math seems to be implemented as meaning 
> that an expression shouldn't be transformed to change the exceptions 
> raised, but exceptions aren't treated as side effects so it can still be 
> discarded if apparently unused, or moved past code that might test or 
> modify exceptions.  Something stricter that actually follows Annex F would 
> treat exceptions more like side effects and eliminate a lot of code 
> movement / dead code removal.  It might be less suitable for the default 
> compilation mode, however.
> 
> I expect there are plenty of bugs even with that more limited description 
> of what -ftrapping-math tries to do.

I was referring to the Annex F of C99 ISO IEC 9899 1999, it says -
"An operation on constants that raises no floating-point exception can be
folded during translation, except, if the state of the FENV_ACCESS pragma is
‘‘on’..."

What is the equivalent of checking FENV_ACCESS on within gcc?

As for this issue, do you think modifying gcc to handle the default case would
be the right start?

Regards,
Sujoy
>From gcc-bugs-return-494832-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 14 13:22:31 2015
Return-Path: <gcc-bugs-return-494832-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 100592 invoked by alias); 14 Aug 2015 13:22:31 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 100536 invoked by uid 48); 14 Aug 2015 13:22:30 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274
Date: Fri, 14 Aug 2015 13:22:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: mpolacek at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-67133-4-XA2v0sqRGQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67133-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67133-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-08/txt/msg00974.txt.bz2
Content-length: 948

https://gcc.gnu.org/bugzilla/show_bug.cgi?idg133

--- Comment #22 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
If infer_nonnull_range_by_attribute can't rely on gimple_call_fntype then we
indeed need to add a check there.

So like this?
--- a/gcc/gimple.c
+++ b/gcc/gimple.c
@@ -2694,10 +2694,13 @@ infer_nonnull_range_by_attribute (gimple stmt, tree op)
      /* Now see if op appears in the nonnull list.  */
      for (tree t = TREE_VALUE (attrs); t; t = TREE_CHAIN (t))
        {
-         int idx = TREE_INT_CST_LOW (TREE_VALUE (t)) - 1;
-         tree arg = gimple_call_arg (stmt, idx);
-         if (operand_equal_p (op, arg, 0))
-       return true;
+         unsigned int idx = TREE_INT_CST_LOW (TREE_VALUE (t)) - 1;
+         if (idx < gimple_call_num_args (stmt))
+       {
+         tree arg = gimple_call_arg (stmt, idx);
+         if (operand_equal_p (op, arg, 0))
+           return true;
+       }
        }
    }
     }

[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN

[ssaraswati at gmail dot com]

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

--- Comment #8 from Sujoy <ssaraswati at gmail dot com> ---
(In reply to joseph@codesourcery.com from comment #7)

> With -fno-signaling-nans, signaling NaN representations are trap 
> representations - the compiler can assume that nothing ever manipulated as 
> a floating-point value has such a representation.  (It cannot assume 
> anything about unions of floating-point and other types where the 
> floating-point field is not accessed.  But 58416 is a bug even in the 
> absence of -fsignaling-nans.)

Ok, have a further question though. For the current test case, which has the
following code -

float sNaN = __builtin_nansf ("")

the sNaN will have a signaling NaN representation. What does
-fno-signaling-nans imply for this situation? Should the compiler assume that
this signaling NaN need not be preserved as this would not lead to a trap? In
other words, can the compiler assume that it can carry out optimizations
without having to care for traps?

As for 58416, looks like this got resolved with revision 196841, where the
i386.md now generates movsd instructions depending on type attribute.

> In both these cases, we formally don't care about the result (but if 
> folding, it still would seem odd to fold incorrectly, so may as well fold 
> to a qNaN).

Ok.

> This point is nothing to do with -fsignaling-nans.  It's a simple matter 
> of C11 F.9.1 paragraph 3, "This specification does not require support for 
> trap handlers that maintain information about the order or count of 
> floating-point exceptions...." (which TS 18661-1:2014, adding support for 
> signaling NaNs, doesn't change).  But it's true that any references to a 
> number of exceptions should make clear it's only referring to the 
> distinction between zero and nonzero numbers.

Right, I think I interpreted the man page text "number of exceptions visible
with signaling NaNs". It probably means the number of types of exceptions and
not the number of exceptions for any given type.

> Local fixes for particular signaling NaNs issues seem reasonable (as in: 
> if you fold an operation involving a signaling NaN, you may as well quiet 
> it in the process, even though signaling NaNs aren't meant to occur in any 
> mode where folding them is likely to be safe).

Thanks, I will prepare a patch to do this. Should I wait for the bug to move to
"new" state, or is it ok to send a fix even though it is marked as
"unconfirmed"?

[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN

[joseph at codesourcery dot com]

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

--- Comment #9 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Tue, 18 Aug 2015, ssaraswati at gmail dot com wrote:

> Ok, have a further question though. For the current test case, which has the
> following code -
> 
> float sNaN = __builtin_nansf ("")
> 
> the sNaN will have a signaling NaN representation. What does
> -fno-signaling-nans imply for this situation? Should the compiler assume that

It implies the compiler can do whatever is convenient.

> this signaling NaN need not be preserved as this would not lead to a trap? In
> other words, can the compiler assume that it can carry out optimizations
> without having to care for traps?

With -fno-signaling-nans the compiler does not need to care about traps 
from signaling NaNs.  It does need to care about traps from quiet NaNs 
(for example, from ordered comparisons or conversion to integer types) 
unless -fno-trapping-math / -ffinite-math-only (the former means no need 
to care about traps, the latter means no need to care about NaNs at all).

> > Local fixes for particular signaling NaNs issues seem reasonable (as in: 
> > if you fold an operation involving a signaling NaN, you may as well quiet 
> > it in the process, even though signaling NaNs aren't meant to occur in any 
> > mode where folding them is likely to be safe).
> 
> Thanks, I will prepare a patch to do this. Should I wait for the bug to move to
> "new" state, or is it ok to send a fix even though it is marked as
> "unconfirmed"?

There is no need to wait for bugs to move state (rather, if working on a 
bug, you may wish to change it to ASSIGNED yourself with yourself as 
assignee).