This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: weird optimization in sin+cos, x86 backend

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


      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

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 <> - Web: <>
100% accessible validated (X)HTML - Blog: <>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]