[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 #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Mon, 24 Apr 2017, vincent-srcware at vinc17 dot net wrote:

> https://sourceware.org/bugzilla/show_bug.cgi?id=21400
> 
> --- Comment #4 from Vincent Lefèvre <vincent-srcware at vinc17 dot net> ---
> (In reply to joseph@codesourcery.com from comment #3)
> > On Thu, 20 Apr 2017, vincent-srcware at vinc17 dot net wrote:
> > > So, if the hardware behaves differently, it should be noted.
> > 
> > The hardware behaves as described there.
> 
> Not all hardware. On Cadence® Tensilica® Fusion G3, min or max of (1,sNaN)
> gives 1 instead of qNaN, as noted in David H.C. Chen's report. But perhaps it
> is not supported by glibc...

I'm referring specifically to AArch64 hardware as a case implementing the 
existing semantics in a single instruction (and which thus did not require 
any glibc changes to its fmin/fmax implementations to implement TS 18661-1 
semantics).  (And I did test on hardware as well as checking the 
architecture specification.)

POSIX has also had TS 18661-1-style requirements for sNaNs for a long 
time: "On implementations that support the IEC 60559:1989 standard 
floating point, functions with signaling NaN argument(s) shall be treated 
as if the function were called with an argument that is a required domain 
error and shall return a quiet NaN result, except where stated otherwise. 
Note: The function might never see the signaling NaN, since it might 
trigger when the arguments are evaluated during the function call.".  
(Although that fails to deal with the various cases where IEEE 754 
explicitly says exceptions do not occur for sNaN arguments, and is 
ambiguous about what counts as stated otherwise; 18661-1 seems a 
better-thought-out version of such semantics.)

Non-associativity would presumably apply equally to hypot: 
hypot(sNaN,hypot(qNaN,Inf)) is qNaN but hypot(hypot(sNaN,qNaN),Inf) is 
Inf.  Of course the IEEE 754 hypot operation (corrected rounded) isn't 
strictly associative for finite arguments anyway.  FWIW, C++17 has a 
three-argument hypot function, but doesn't specify how infinities and NaNs 
are handled by it.

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