https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121525
--- Comment #5 from Segher Boessenkool <segher at gcc dot gnu.org> --- (In reply to Joseph S. Myers from comment #4) > If you pass _Float16 in a double precision register, note potential > signaling NaN issues - preferably a signaling NaN of type _Float16 should be > passed as a signaling NaN so that callees that distinguish quiet and > signaling NaNs can do so (powf16 etc.). (And likewise for return values, of > course.) > > This isn't a problem for single precision on Power because of load/store > instructions whose conversions between single and double precision are > defined as purely bitwise operations (and, in particular, do not convert > signaling NaNs to quiet). I don't know whether the half precision conversion > instructions include ones with the same property that's convenient for > implementing such an ABI, however. None of the load/store insns (for HP or otherwise) ever change a quiet NaN to a signaling NaN or the other way around. Oh and luckily we (and library writers) almost never have to do anything for signaling NaNs: the hardware will raise an exception if such a value is used, and that is that. If you do not handle this in some spot, then some later spot will raise an error without the programmer having to do anything about it :-) Converting to bigger floating point types is almost never a problem btw, but downconverting often is. Look at the six actually different ways that bfloat16 is implemented for example (edge cases *matter*, oh and a NaN should never turn into an infinity, as happens with many bfloat16 implementations!)
