[PATCH]: PR29335 evaluate transcendentals@compile-time using MPFR

[Kaveh R. GHAZI]

On Mon, 9 Oct 2006, Joseph S. Myers wrote:

> On Mon, 9 Oct 2006, Richard Guenther wrote:
>
> > Does it work correctly with cross-compiling and weird host/target float
> > formats?
>
> real.c still exists to handle encoding/decoding the various target float
> formats (host float formats should be, and remain, irrelevant).  I don't
> know about handing details such as presence/absence of infinities,
> denormals etc.; MPFR won't solve the issues with handing fundamentally
> non-IEEE formats (IBM long double with its discontiguous bits), but for
> the transcendental functions it really should be sufficient to treat IBM
> long double as a normal floating point type with 106 or 107 bits of
> mantissa.

One of the issues I'm not sure about is how much MPFR precision I should
request when initializing an MPFR variable via mpfr_init2().  Right now I
simply hardcode 128 like the fortran front end does in
arith.c:gfc_arith_init_1().  I also hardcode a buffer size of 256 in the
intermediate string that holds values being converted between
REAL_VALUE_TYPE and mpfr_t.  See real_from_mpfr() and mpfr_from_real() in
my original patch.


> The biggest potential problem is that, as per FSF policies, we can't alter
> the code imported from other GNU projects; any fixes must be through
> changes outside the gmp and mpfr directories or else through importing new
> upstream versions of GMP and MPFR.

Of course bug fixes and the like should be pushed upstream first.

However my understanding is that changes required to get the imported code
working in the GCC directory with no general relevance to parties outside
of GCC can and should be made locally.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu