On Sat, 7 Nov 2015, Richard Sandiford wrote: > - the call to sqrt is protected by the result of the optab rather > than the input. It would be better to check !(x >= 0), like > tree-call-cdce.c does.
Well, no, isless (x, 0) (or !isgreaterequal (x, 0), since it doesn't matter what result a NaN gets). If a quiet NaN is the argument, the "invalid" exception should not be raised, which >= will do (modulo bugs on some targets where unordered comparison instructions are wrongly used for ordered comparisons). Bug 68264 filed. > +/* Return true if CALL can produce a domain error (EDOM) but can never > + produce a pole or range overflow error (ERANGE). This means that we > + can tell whether a function would have set errno by testing whether > + the result is a NaN. > + > + Note that we do not consider range underflow errors, which are > + implementation-defined in C99. */ I'd think this should respect the library's definition. For glibc that is that underflow to 0 should set errno if the result would also underflow to 0 in the default rounding mode, but underflow to subnormal result doesn't need to set errno, and neither does rounding-mode-dependent underflow to 0 in cases where f (x) is very close to x for small x but in some rounding modes f of the least subnormal is 0. (That caveat around f (x) close to x avoids possibly needing to set errno for the least subnormal only for lots of functions.) > + CASE_FLT_FN (BUILT_IN_EXP): > + CASE_FLT_FN (BUILT_IN_EXP10): > + CASE_FLT_FN (BUILT_IN_EXP2): > + CASE_FLT_FN (BUILT_IN_EXPM1): These can overflow. > + CASE_FLT_FN (BUILT_IN_ATAN2): And this is the only case here where, given that caveat, underflow setting ERANGE is applicable with glibc, but overflow is not. -- Joseph S. Myers jos...@codesourcery.com
