[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441 --- Comment #15 from Jakub Jelinek --- Author: jakub Date: Tue Feb 21 08:08:40 2017 New Revision: 245620 URL: https://gcc.gnu.org/viewcvs?rev=245620&root=gcc&view=rev Log: PR tree-optimization/61441 * simplify-rtx.c (simplify_const_unary_operation): For -fsignaling-nans and sNaN operand, return NULL_RTX rather than the sNaN unmodified. Modified: trunk/gcc/ChangeLog trunk/gcc/simplify-rtx.c
[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #14 from Uroš Bizjak --- Testsuite patch committed. Fixed.
[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441 --- Comment #13 from Uroš Bizjak --- (In reply to Thomas Preud'homme from comment #12) > I encountered the same issue (undefined reference to `issignaling') on > arm-none-eabi which is due to newlib's math.h not providing the issignaling > macro so this should be reported against newlib. Testsuite patch at [1]. [1] https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00921.html
[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441 Thomas Preud'homme changed: What|Removed |Added CC||thopre01 at gcc dot gnu.org --- Comment #12 from Thomas Preud'homme --- I encountered the same issue (undefined reference to `issignaling') on arm-none-eabi which is due to newlib's math.h not providing the issignaling macro so this should be reported against newlib.
[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441 --- Comment #11 from Andreas Schwab --- FAIL: gcc.dg/pr61441.c (test for excess errors) Excess errors: /usr/local/gcc/gcc-20151223/gcc/testsuite/gcc.dg/pr61441.c:12:7: warning: implicit declaration of function 'issignaling' [-Wimplicit-function-declaration] pr61441.c:(.text+0x22): undefined reference to `issignaling' pr61441.c:(.text+0xe2): undefined reference to `issignaling' pr61441.c:(.text+0x162): undefined reference to `issignaling' UNRESOLVED: gcc.dg/pr61441.c compilation failed to produce executable
[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441 --- Comment #10 from Sujoy --- (In reply to jos...@codesourcery.com from comment #9) > 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). Ok, I started working on this and hope to send a fix soon.
[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441
--- Comment #9 from 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).
[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441
--- Comment #8 from Sujoy ---
(In reply to jos...@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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441 --- Comment #7 from joseph at codesourcery dot com --- On Fri, 14 Aug 2015, ssaraswati at gmail dot com wrote: > --- Comment #6 from Sujoy --- > (In reply to jos...@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. 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.) > 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. 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). > > 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? 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. > 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? -ftrapping-math -frounding-math (but as I noted, -ftrapping-math doesn't really cover everything it should for that purpose, and something that did might not be suitable for enabling by default). > As for this issue, do you think modifying gcc to handle the default case would > be the right start? 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).
[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441 --- Comment #6 from Sujoy --- (In reply to jos...@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
[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441 --- Comment #5 from 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441 --- Comment #4 from Sujoy --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441 --- Comment #3 from 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441 Sujoy changed: What|Removed |Added CC||ssaraswati at gmail dot com --- Comment #2 from Sujoy --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org Component|target |tree-optimization --- Comment #1 from Ramana Radhakrishnan --- 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.
