This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gfortran.dg/large_real_kind_1.f90


On Wed, Sep 28, 2005 at 09:12:48PM +0200, Tobias Schl?ter wrote:
> Steve Kargl wrote:
> > I inserted
> > 
> >       mpfr_out_str(stderr, 10, 0, real_info->huge, GFC_RND_MODE);
> >       fprintf(stderr, "\n");
> > 
> > in arith.c to use MPFR's output routine for the values of huge.
> > On my opteron, I see
> > 
> > 3.4028235e38
> > 1.797693134862316e308
> > 1.1897314953572317650e4932
> > 
> > So, whatever is spitting out t0.original is broken (including possibly
> > FreeBSD's libc).
> 
> gfc_conv_mpfr_to_tree (especially build_real) can also be the culprit.
> 

Yep. gfc_conv_mpfr_to_tree appears to be the culprit.  The attach
patch gives the expected value of

  c = 1.18973149535723176502126385303097020516906332229462420044e+4932;

in s.f90.t0.original.

This was bootstrapped and regression tested on FreeBSD-*-amd64.
Two files, fold_nearest.f90 and past_eor.f90, reveal regressions.
I think the floating point comparison test in past_eor.f90 may be
bogus.  The guts on past_eor.f90 are

  e = (/2.34,2.456/)

  buffer = '  2.34 ,  2.456     2.34 ,  2.456     0.234E01,  2.456E00&
 &   0.234E+001, 2.456E-000'

   READ (UNIT=buffer,FMT=10) a, b, c, d
10 FORMAT (2(2(G7.5,1X),2X),2(G10.4E2,1X),1X,2(G11.7E4,1X))

  if (any(a.ne.e).or.any(b.ne.e).or.any(c.ne.e).or.any(d.ne.e)) call abort ()

This is a floating point comparison, which may be bogus, due the conversion
of decimal strings to real numbers.  I'll note that print statements in
past_eor.f90 produced the expected decimal output.


The failure of fold_nearest.f90 is troublesome.  I need to look
into what nearest() returns, but I thought it was the nearest
exactly representable number.  This should permit floating point
comparison for equality.  Again, print statements in fold_nearest.f90
yield the expected output, which suggest a possible ULP problem. 

One other item to note,  the lines of code that are commented out
in fold_nearest.f90 can be uncommented.  Tobi and I fixed the
handling of subnormal numbers. 

Note:  I'll fix fold_nearest.f90 and past_eor.f90 if others 
agree the floating point comparison are bogus.

2005-09-28  Steven G. Kargl <kargls@comcast.net>

	* trans-const.c (gfc_conv_mpfr_to_tree):  Fix hexadecimal conversion of
	mpfr nubmers.

-- 
Steve     

Attachment: trans-const.c.diff
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]