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).
