weird optimization in sin+cos, x86 backend

[Joseph S. Myers]

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
joseph@codesourcery.com