[Bug manual/21400] Section "Infinity and NaN" of the libc manual

["joseph at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=21400

--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Thu, 20 Apr 2017, vincent-srcware at vinc17 dot net wrote:

> https://sourceware.org/bugzilla/show_bug.cgi?id=21400
> 
> --- Comment #2 from Vincent Lefèvre <vincent-srcware at vinc17 dot net> ---
> (In reply to joseph@codesourcery.com from comment #1)
> > Note that the full IEEE 754 semantics of fmin/fmax, including that sNaN 
> > maps to qNaN but qNaN arguments are ignored, are implemented in hardware 
> > on AArch64 at least (that is, the present functions can be implemented by 
> > a single instruction on AArch64).
> 
> https://www.gnu.org/savannah-checkouts/gnu/libc/manual/html_node/Infinity-and-NaN.html
> says about the macro FE_SNANS_ALWAYS_SIGNAL:
> 
> "This macro, defined by TS 18661-1:2014, is defined to 1 in fenv.h to indicate
> that functions and operations with signaling NaN inputs and floating-point
> results always raise the invalid exception and return a quiet NaN, even in
> cases (such as fmax, hypot and pow) where a quiet NaN input can produce a
> non-NaN result."
> 
> So, if the hardware behaves differently, it should be noted.

The hardware behaves as described there.  My point is that you seemed to 
be suggesting some change in semantics from the current IEEE 754 / TS 
18661 semantics that can be implemented with a single hardware instruction 
on current hardware, to some other semantics that would be less efficient.

-- 
You are receiving this mail because:
You are on the CC list for the bug.