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