------- Comment #5 from ghazi at gcc dot gnu dot org 2006-10-06 15:36 ------- (In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > >> (In reply to comment #0) > >>> > > idea of what mpfr can do. My main area of concern right now is converting > > between gcc's REAL_VALUE_TYPE and mpfr_t. I found gfc_conv_mpfr_to_tree() > > in > > trans-const.c which uses a string as an intermediate type, is that the most > > efficient way to convert? > I didn't write that function, and so I have experimented with a replacement. > There is mpfr_get_ld(), which converts to a long double. If the data type > never exceeds the properties of long double, then one may be able to > use mpfr_get_ld() and then fold_convert() the result to the proper type.
I think using long double defeats the whole purpose of using mpfr. We're supposed to avoid relying on the properties of the host's floating point for cross-compilers where the target format is different. Otherwise I could simply call out to e.g. cosl() on the host and avoid the whole mpfr thing (okay okay, assuming cosl() and the rest of c99 math functions exist... which they don't always, but my point about target long double remains.) I was hoping there was an easy was to extract the exponent and mantissa from one of (REAL_VALUE_TYPE/mpft_t) and put them back into the other in a way that preserves everything clean in both directions. > > Also where is the function that does the reverse, > > i.e. tree or REAL_VALUE_TYPE to mpfr_t? > gfortran doesn't have a need of going in the opposite direction. > gmp/mpfr are used in the frontend for the internal representation > of data types. By the time gfortran reaches the functions in > trans-*.c, it has done all the constant folding and manipulation > of the data types that it can. The trans-*.c functions simply > convert gfortran's black and red trees into the tree-ssa form. Okay I hacked up something in the other direction using strings again. If someone comes up with something better, then great. But it's not strictly necessary. I can put the two conversion functions into real.[ch]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
