[v3] Possible fix for PR 5730

jlquinn@optonline.net jlquinn@optonline.net
Wed Mar 19 18:02:00 GMT 2003



----- Original Message -----
From: Gabriel Dos Reis <gdr@integrable-solutions.net>
Date: Wednesday, March 19, 2003 9:16 am
Subject: Re: [v3] Possible fix for PR 5730

> Jerry Quinn <jlquinn@optonline.net> writes:
> 
> | I just tried the test case comparing gcc 2.95 and 3.3 branch.  
> The gap is now
> | smaller than the reporter saw, but it is there:
> | 
> | gcc 2.95     1.2s
> | gcc 3.3             1.6s
> | 
> | Can someone that actually understands floating point explain the 
> accuracy| improvement with the current implementation?  
> Mathematically (ignoring fp
> | limitations), they are equivalent.  So how does the distinction 
> show up with
> | actual fp math?
> | 
> | Anyway, I thought that if the more accurate answer is required, 
> the faster
> | solution could still be used under --fast-math.  Opinions?
> 
> I would prefer we do not duplicate code but use something along the 
> line:
>  template<typename _Tp>
>    inline _Tp
>    norm(const complex<_Tp>& __z)
>    {
>      return _Norm_helper<__FAST_MATH__ || 
> __is_floating<_Tp>::_M_type>                  ::_S_do_it(__z);
>    }

This is certainly cleaner.  I like it.

> Now, I realize the macro __FAST_MATH__ may not be defined with
> definite value -- that is really sad.  

Why not?  It's controlled by the compiler, and the compiler is linked to the v3 library.  So we should be able to dictate what it is set to, no?

> Then maybe we want to add this to the config file
> 
> #ifdef __FAST_MATH__
> # define _GLIBCPP_FAST_MATH 1
> #else
> # define _GLIBCPP_FAST_MATH 0
> #endif
> 
> and use _GLIBCPP_FAST_MATH. 

I presume you mean c++config.h?  Where do I look to set this up correctly?

Jerry





More information about the Libstdc++ mailing list