Re: [v3] Possible fix for PR 5730

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

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 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);
    }

Now, I realize the macro __FAST_MATH__ may not be defined with
definite value -- that is really sad.  
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. 


-- Gaby