Re: weird optimization in sin+cos, x86 backend

[Vincent Lefevre <vincent+gcc at vinc17 dot org>]

On 2012-02-15 15:18:45 +0000, Andrew Haley wrote:
> On 02/15/2012 09:30 AM, Vincent Lefevre wrote:
> >> But to be absolutely clear, glibc's libm doesn't have a problem
> >> > meeting C99, AFAIK.
> > That's not quite correct. It is completely broken in directed
> > rounding modes (up to crashes).
> 
> Eh?  C99 doesn't require directed rounding modes.  I'll grant you,
> if they are provided they shouldn't crash.  :-)

C99 doesn't require directed rounding modes, but as long as they
are claimed to be supported by <fenv.h>, they should work:

      7.6 Floating-point environment <fenv.h>

   7  Each of the macros

        FE_DOWNWARD
        FE_TONEAREST
        FE_TOWARDZERO
        FE_UPWARD

      is defined if and only if the implementation supports getting
      and setting the represented rounding direction by means of
      the fegetround and fesetround functions. Additional
      implementation-defined rounding directions, with macro
      definitions beginning with FE_ and an uppercase letter, may
      also be specified by the implementation. The defined macros
      expand to integer constant expressions whose values are
      distinct nonnegative values.183)

This is the case with GCC + glibc on x86_64 (but not on ARM, for
instance).

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).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)