Discrepancies in real.c:mpfr_to_real and fortran/trans-const.c:gfc_conv_mpfr_to_tree?

[Brooks Moses]

I was looking through how to convert real numbers between various 
representations for the Fortran TRANSFER patch that I'm working on, and 
came across something that I'm curious about.

We've currently got two different bits of code for converting an MPFR 
real number to a REAL_VALUE_TYPE.  One of them's at the end of 
gcc/real.c, in mpfr_to_real; the other is in fortran/trans-const.c, in 
gfc_conv_mpfr_to_tree.

There are a couple noteworthy differences, at least one of which looks 
like a bug.

First, gfc_conv_mpfr_to_tree as the following bit of code and comment:
-----------------------------------------------------------------------
   /* mpfr chooses too small a number of hexadecimal digits if the
      number of binary digits is not divisible by four, therefore we
      have to explicitly request a sufficient number of digits here.  */
   p = mpfr_get_str (NULL, &exp, 16, gfc_real_kinds[n].digits / 4 + 1,
		    f, GFC_RND_MODE);
-----------------------------------------------------------------------

In mpfr_to_real, however, the parameter for the number of digits is 
simply 0, letting mpfr do the choosing.  I don't have any idea whether 
this is in fact a bug-in-potentia, but it looks quite suspicious.

If this is a bug, what would be the appropriate GCC equivalent for 
gfc_real_kinds[n].digits?

Second, gfc_conv_mpfr_to_tree has code to handle Inf and NaN values, 
whereas mpfr_to_real doesn't.  This seems like it might be worth porting 
over.  Comments?

Then there is the fact that there are two separate functions doing the 
same thing, which itself seems like a misfeature.  (There is one slight 
difference; the gcc one uses GMP_RNDN as the rounding mode, while the 
fortran one uses GFC_RND_MODE, which is #defined to GMP_RNDN; this could 
plausibly be a reason not to combine them.)

Finally, is writing the value to a human-readable string and then 
parsing it really the simplest way to convert between an mpfr 
representation and a REAL_VALUE_TYPE?  I can imagine that it is, but 
still: Wow.  :)

- Brooks