This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug manual/21400] Section "Infinity and NaN" of the libc manual
- From: "vincent-srcware at vinc17 dot net" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 24 Apr 2017 08:37:16 +0000
- Subject: [Bug manual/21400] Section "Infinity and NaN" of the libc manual
- Auto-submitted: auto-generated
- References: <bug-21400-131@http.sourceware.org/bugzilla/>
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.