This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [gfortran] Fix NEAREST constant folder
- From: Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>
- To: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- Cc: GCC Fortran mailing list <fortran at gcc dot gnu dot org>,patch <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 12 Apr 2005 12:08:29 +0200
- Subject: Re: [gfortran] Fix NEAREST constant folder
- References: <4259364C.3040109@physik.uni-muenchen.de> <20050410150114.GA4469@troutmask.apl.washington.edu>
Steve Kargl wrote:
> MPFR does not support subnormal numbers, so there isn't much you
> can do. If you don't range_check, then underflows elsewhere will
> be treated as if you set the result to zero. It's concievable that
> someone may use nearest(0,1) to avoid division by zero. So, I
> think our only option is to return +-tiny(). I suggest we have
> a comment with this info in the source and perhaps issue a warning
> that gfortran does not currently support subnormal numbers.
IOW we can't get compile-time arithmetic right with mpfr? This is very
unfortunate. (Another possible application for NEAREST(0.,1.) is to check for
the existence of denormals: NEAREST(0.,1.) < TINY(0.) should be true iff the
machine representation supports subnormals)
> OK to commit to mainline. OK for 4.0 branch when Mark re-opens the
> branch.
After I had committed this, I realized that my testcase doesn't test double
precision numbers, so I tried adding a few tests for double precision to the
testcase but they all failed. After a close look the constant folder appears
to do the right thing, and the library implementation simply calls nexafter()
from the C library so I believe the culprit is gfc_conv_mpfr_to_tree (maybe
we're losing precision because we go via a decimal string?), I'll investigate
this further tomorrow.
- Tobi