On Thu, 16 Feb 2012, Vincent Lefevre wrote: > Note that <math.h> functions are not required to honor the rounding > direction mode (F.9#10). So, locally resetting the rounding mode to > nearest in these functions would be correct, I think (I don't know > how this can affect signal handlers, when a signal occurs during the > computation of a math function).
We made it explicit for C11 that the floating-point environment was unspecified in signal handlers (5.1.2.3#5: "When the processing of the abstract machine is interrupted by receipt of a signal, the values of objects that are neither lock-free atomic objects nor of type volatile sig_atomic_t are unspecified, as is the state of the floating-point environment." - this was my comment BSI 1 on C1X). (C99 just referred to objects there.) Although concerns had been expressed in the past about the signal handler issue, I think it's been established for some time that it *is* OK to change and restore the rounding mode within libm functions. (Even when the concerns were being expressed, there were various functions that did in fact save and restore it - and for some operations on some architectures, GCC generates inline code that does so.) So it is fine to make such changes, and they should be done whenever the implementation of a function depends on being executed in round-to-nearest mode. There's even a macro libc_feholdexcept_setround, with variants libc_feholdexcept_setroundf and libc_feholdexcept_setround, to use if you know the operations will be on one particular type (these macros will be paired with those such as libc_fesetenv and libc_feupdateenv). I encourage the submission of such patches (with, where possible, testcases that illustrate the problems the functions had in directed rounding modes). Or bug reports if there aren't any currently open for the particular function (if such a bug report was wrongly closed WONTFIX or INVALID, please feel free to reopen it). -- Joseph S. Myers jos...@codesourcery.com
