On Fri, 27 Nov 2020, Florian Weimer via Gcc wrote: > The nature of these non-normal numbers is that the CPU does not produce > them. I think we should make sure that glibc doesn't, either, with > obvious exceptions such as memcpy. But beyond that, I don't know.
Exceptions probably also include the non-computational functions that just manipulate the sign bit (fabsl and copysignl). And likewise the <complex.h> functions conjl, creall, cimagl. (For all of these, built-in functions would normally be expanded inline rather than using the library version anyway.) > > At the minimu ISTM that we should at least make the classification > > consistent with gcc. > > Yes, I agree. If you want to be consistent with how the processor interprets these as invalid operands, that would also mean issignaling treats all these invalid operands as signaling NaNs. We haven't so far tried to make <complex.h> functions do anything in particular with signaling NaNs (TS 18661-1 and C2x leave it implementation-defined how they are handled in such functions). Arguably the functions other than those listed above should return (qNaN, qNaN) for any complex argument with at least one part sNaN (and thus for any complex argument with at least one part an invalid operand) rather than treating operands with one part sNaN and one Inf as an infinity. (cabs should already do that, via its use of hypot which does handle sNaN.) -- Joseph S. Myers jos...@codesourcery.com
