This is the mail archive of the
`gcc@gcc.gnu.org`
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] |

*From*: Vincent Lefevre <vincent+gcc at vinc17 dot org>*To*: gcc at gcc dot gnu dot org*Date*: Thu, 16 Feb 2012 15:42:20 +0100*Subject*: Re: weird optimization in sin+cos, x86 backend*References*: <5CEA5397-B4FB-4E5F-B915-E67887C0D68E@adacore.com> <20120213141401.GC26414@xvii.vinc17.org> <1D6D65C6-1686-4084-B1F6-66BEBD730502@adacore.com> <20120214132254.GF26414@xvii.vinc17.org> <8E140C88-12FA-4F8E-A157-76AB8CCDAFAB@adacore.com> <4F3A8F84.3060106@redhat.com> <02218B28-E5E7-4DF2-87F1-B041A465CE87@adacore.com> <4F3A9434.4070904@redhat.com> <20120215093015.GA28757@xvii.vinc17.org> <4F3BCCD5.2090108@redhat.com>

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)

**Follow-Ups**:**Re: weird optimization in sin+cos, x86 backend***From:*Andrew Haley

**Re: weird optimization in sin+cos, x86 backend***From:*Joseph S. Myers

**References**:**Re: weird optimization in sin+cos, x86 backend***From:*Geert Bosch

**Re: weird optimization in sin+cos, x86 backend***From:*Vincent Lefevre

**Re: weird optimization in sin+cos, x86 backend***From:*Geert Bosch

**Re: weird optimization in sin+cos, x86 backend***From:*Vincent Lefevre

**Re: weird optimization in sin+cos, x86 backend***From:*Geert Bosch

**Re: weird optimization in sin+cos, x86 backend***From:*Andrew Haley

**Re: weird optimization in sin+cos, x86 backend***From:*Geert Bosch

**Re: weird optimization in sin+cos, x86 backend***From:*Andrew Haley

**Re: weird optimization in sin+cos, x86 backend***From:*Vincent Lefevre

**Re: weird optimization in sin+cos, x86 backend***From:*Andrew Haley

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |