https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #13 from joseph at codesourcery dot com ---
On Fri, 10 Nov 2023, rguenth at gcc dot gnu.org via Gcc-bugs wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
>
> --- Comment #11 from Richard Biener ---
> (In reply to post+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #12 from post+gcc at ralfj dot de ---
> GCC will not create an sNaN out of nowhere.
That's the part I was hoping for. :) I just don't think it obviously follows
from any docs (the C standard or GCC docs).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #11 from Richard Biener ---
(In reply to post+gcc from comment #10)
> The standard says
>
> > This annex does not require the full support for signaling NaNs specified
> > in IEC 60559. This
> annex uses the term NaN, unless explic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #10 from post+gcc at ralfj dot de ---
The standard says
> This annex does not require the full support for signaling NaNs specified in
> IEC 60559. This
annex uses the term NaN, unless explicitly qualified, to denote quiet NaNs.
Whe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #9 from joseph at codesourcery dot com ---
To quote the C23 DIS, "This annex does not require the full support for
signaling NaNs specified in IEC 60559. This annex uses the term NaN,
unless explicitly qualified, to denote quiet Na
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
Richard Biener changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #7 from post+gcc at ralfj dot de ---
I guess the idea is that by passing a signaling NaN to a float operation, I am
already entering unspecified behavior, so it's okay for that float operation to
violate its usual contract and return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #6 from post+gcc at ralfj dot de ---
Hm, OTOH the C standard says
> The expressions 1×x, x/1, and x are equivalent (on IEC 60559 machines, among
others).
So, it seems like when they say "The + ,- , * , and / operators provide the IE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #5 from post+gcc at ralfj dot de ---
> See
> https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fsignaling-nans
That's unrelated. That's about whether operation on signaling NaNs can trap. I
am asking when operations can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #4 from Andrew Pinski ---
And documented other parts here:
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/cpp/Common-Predefined-Macros.html
specifically:
It does not indicate whether optimizations respect signaling NaN semantics (the
ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #3 from Andrew Pinski ---
GCC does document some of this on
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Floating-point-implementation.html
but not the signaling nan part.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #2 from Andrew Pinski ---
Note mips and sh and a few other targets have the quiet bit meaning the
opposite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #1 from Andrew Pinski ---
See
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fsignaling-nans
13 matches
Mail list logo
