------- Comment #28 from burnus at gcc dot gnu dot org 2009-07-15 09:41 -------
(In reply to comment #24)
> So maybe approach the question differently. Which element in an array of NaNs
> is the smallest one and what is its value? If I pick any one element, its
> "value" is NaN. It does not matter which one I select, its "value" always
> comes out NaN.
Well, according to IEEE 754:2008 the result is the "canonicalized" NaN, which
is implementation defined. NaNs have a sign and may have different bit patterns
("payload") but I think we can ignore those. To be conforming, the NaN should
match one of the NaNs in the list. (I think the latter will automatically be
the case, but even if not, I think essentially no one will care.)
(In reply to comment #25)
> Now, I have another question: what happens for mixed NaNs? For example, in
> your scheme, what would be the value of MAXVAL((/sNaN, qNaN/))?
If FP trapping is enabled => SIGFPE, if not, treat it like a quiet NaN. Whether
MAXVAL([x,y]) returns X or Y is implementation defined and thus the result can
be an (untrapped) sNan or qNaN.
For completeness, IEEE 754:2008 defines (in 5.3.1):
"maxNum(x, y) is the canonicalized number y if x < y, x if y < x, the
canonicalized number if one operand is a number and the other a quiet NaN.
Otherwise it is either x or y, canonicalized (this means results might differ
among implementations). When either x or y is a signaling NaN, then the result
is according to 6.2."
(Note regarding "floating-point number": That includes +/-INF but not NaN.)
and (in 6.2.3)
"If two or more inputs are NaN, then the payload of the resulting NaN should be
identical to the payload of one of the input NaNs if representable in the
destination format. This standard does not specify which of the input NaNs will
provide the payload."
* * *
See also PR 40643.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694
