This is the mail archive of the
mailing list for the libstdc++ project.
Re: [v3] Possible fix for PR 5730
- From: jlquinn at optonline dot net
- To: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Wed, 19 Mar 2003 12:59:22 -0500
- Subject: Re: [v3] Possible fix for PR 5730
----- Original Message -----
From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
Date: Wednesday, March 19, 2003 9:16 am
Subject: Re: [v3] Possible fix for PR 5730
> Jerry Quinn <jlquinn at optonline dot 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
> 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
> # define _GLIBCPP_FAST_MATH 0
> and use _GLIBCPP_FAST_MATH.
I presume you mean c++config.h? Where do I look to set this up correctly?