------- Comment #8 from joseph at codesourcery dot com 2009-04-20 17:30 ------- Subject: Re: real.c rounding not perfect
On Mon, 20 Apr 2009, ghazi at gcc dot gnu dot org wrote: > How about chucking real.c and using mpfr_t as the internal representation for > real numbers inside GCC? I guess we still need something to encode/decode > numbers to the target format, but IMHO we'll keep finding these corner cases > until we convert everything over to MPFR underneath the hood. At that point, > what's the use of having the extra layer of real.c? I sort of imagine that real.c should provide a wrapper layer that checks whether the real number is decimal (in which case it calls the dfp.c code which uses libdecnumber) or binary (in which case it uses MPFR, taking care to use the correct precision, range, subnormal handling etc. for the type in question) or split-binary (IBM long double) in which case it should use more complicated GCC-local code that ultimately uses MPFR underneath (bug 19779, bug 26374) - certainly the implementation should avoid causing problems for future split-binary folding implementation. (A base class from which implementations for decimal, binary and split-binary derive, if you wish.) I don't see any need for GCC to have its own implementation of the binary arithmetic - but it will need its own encoding/decoding support for all the many supported formats. I also wonder if the code for handling target formats and arithmetic on them should in principle be a library shared with GDB (which presently uses host floating-point arithmetic) but wouldn't like to try to persuade GDB to require MPFR. > Another option would be to put an mpfr_t inside struct real_value instead of > all those bitfields. You'd need to deal with the memory allocation/deallocation requirements, the MPFR allocation model is rather different from the fixed-size structures presently used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
