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.
