[Bug c++/49813] [C++0x] sinh vs asinh vs constexpr

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813

--- Comment #52 from rguenther at suse dot de <rguenther at suse dot de> 2011-07-28 09:26:40 UTC ---
On Wed, 27 Jul 2011, ghazi at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
> 
> --- Comment #50 from Kaveh Ghazi <ghazi at gcc dot gnu.org> 2011-07-27 23:13:18 UTC ---
> (In reply to comment #46)
> > Another note, about std::nextafter, std::nexttoward, & co: I see mpfr provides
> > an mpfr_nexttoward, which likely could be exploited in builtins.c pretty
> > easily. 
> > Kaveh, do you have any plan about those?
> 
> It's been several years since I did the mpfr work so my memory is a little
> foggy, but I think I intentionally skipped the next* functions.  IIRC, these
> functions are very sensitive to the target floating point format.  It wasn't
> clear to me that the "next" FP value in mpfr actually corresponded to the
> "next" value in the target FP format or how to verify if it was so.  (I'm
> thinking mainly of the non-ieee formats here.)  
> 
> If these odd formats aren't used in GCC anymore then it might be okay to
> implement the builtins using mpfr.  Alternatively, you can implement the
> builtins only for the formats where mpfr's format is identical to the target fp
> format.  But then the optimization won't work everywhere so your library
> testcase will fail on some cpus.
> 
> I'm not sure it's worth the trouble (and to answer your question I don't have
> any plans to work on it.)

I think the next* functions should be done with real.c stuff as it could
be indeed dependent on the target format.

Richard.