[Bug c++/49813] [C++0x] sinh vs asinh vs constexpr
rguenther at suse dot de
gcc-bugzilla@gcc.gnu.org
Thu Jul 28 09:28:00 GMT 2011
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.
More information about the Gcc-bugs
mailing list