This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

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

No, it seems that minNum, etc. will probably be removed from IEEE 754 and new
operations added. So, the best way for TS 18661 would be to drop fmin/fmax spec
concerning sNaN (i.e. leave it undefined), at least until things get clearer on
the IEEE 754 side.

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]