> 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.
Yeah, the fortran one predated mine and didn't do quite what I wanted. It only transformed in one direction. So I wrote complementary (and hopefully generic/reusable) versions for both directions and put them in the middle-end. > 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. It's not a bug. When the first parameter is NULL, mpfr allocates sufficient space on the fly. So using 0 for the number of digits is correct. Note there is a call to mpfr_free_str several lines down. However having it malloc on every call may not be optimal. Perhaps if we created a char array on the stack of sufficient size we could avoid that. I wasn't sure how big it needed to be to ensure it worked for every target float format mantissa size. Suggestions/refinements welcome. > 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? The compile-time opts I wrote never pass in Inf or NaN. It avoids me having to worry about various different errno and/or floating point exceptions (which I can't set) and the various different standards that mandate different behaviors. Avoids lots of headaches and potential bugs. If you wanted to use these routines for other purposes that make use of these values, then by all means you could extend them to handle these two inputs. > 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.) As I mentioned, the fortran one predated my code in the middle end. If fortran wants to use the generic middle-end code, that's fine with me. I wasn't sure if the subtle difference mattered so I left it up to a fortran maintainer. > 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 It worked for me. Roger suggested that a more efficient binary conversion should be possible, but I never felt there was a pressing need. If you find these conversion routines to be a bottleneck, then perhaps it would be worth investigating this route. Until then, I wouldn't fix what isn't broken. :-) http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01176.html Hope this helps, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
