https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441
--- Comment #8 from Sujoy <ssaraswati at gmail dot com> ---
(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"?
