This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [PATCH/gfortran] Fix rounding in constant folding
On Sat, Apr 09, 2005 at 07:31:26PM +0200, Tobias Schl?ter wrote:
> Steve Kargl wrote:
> > * gfortran.dg/nint_1.f90: New test.
> > * gfortran.dg/anint_1.f90: ditto.
>
> Please add tests for dnint and put all tests into a single testcase. Please
> also add tests for negative constants. (I think the higher granularity we
> gain by testing everything individuality is more than offset by the additional
> time it takes the testsuite to run.)
Okay, I'll combine the tests. I'll need to think about the negative
numbers.
> > program nint_1
> > if (nint(8388609.0) /= 8388609) call abort
> > if (nint(0.49999997) /= 0) call abort
> > end program nint_1
>
> I would argue for calculating these magic numbers from the model numbers, i.e.
> use nint (nearest (0.5, -1.)). Unfortunately, my argument fails the real-life
> test: nint(nearest(...)) gives the correct result (=zero) with an unpatched
> compiler on my box, whereas the literal constant from your example doesn't.
The magic numbers are from Geert Bosch's email
http://gcc.gnu.org/ml/fortran/2005-04/msg00148.html
I just checked our constant folding in simplify.c for nint and anint.
The change for dnint is obvious after noticing the failures in nint
and anint.
> In order of increasing probability: Does mpfr round incorrectly? Do we do
> something wrong? Or am I being stupid?
Yes, mpfr_round() rounds correctly (assuming that there are no bugs in mpfr).
The problem is we implemented the naive algorithm (as given in
the standard) for nint, anint, and dnint
if (x > 0)
x = int(x+0.5)
else
x = int(x-0.5)
which may be suffering from double rounding. Also note, we set mpfr
to round to nearest via "#define GFC_RND_MODE GMP_RNDN".
--
Steve