This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: gfortran.dg/large_real_kind_1.f90
On Wed, Sep 28, 2005 at 05:19:54PM +0930, Alan Modra wrote:
> On Tue, Sep 27, 2005 at 08:49:39PM -0700, Steve Kargl wrote:
> >
> > The numerical inquiry functions are defined in the Fortran
> > 95 standard in terms of model numbers. The fundamental
> > parameters are radix b, digits p, and emin and emax (minimum
> > and maximum exponent). Huge(x) returns the maximum value for
> > the model number associated with x not the maximum value for
> > the machine representable number for x. Of the three choices
> > you list above, (a) is IMHO the correct solution. BTW, what
> > are b, p, and emax in IBM extended double format and what is
> > the value of huge() you expect?
>
> b is 2, p is 106, emax is 1024. I would expect huge() to equal C's
> __LDBL_MAX__, which is what my patch does. If we lie and set emax to
> 1023, then we'd have "1.1 * huge()" not equal to infinity, which I
> imagine might cause other problems.
>
Can you compile the program that follows my .sig with -fdump-tree-original
and report the values? Note, please change the definition of the
integer kb to be whatever the kind type parameter for IBM extended
double is.
On my opteron based FreeBSD system, my s.f90.t0.original contains
ba = 2;
bb = 2;
bc = 2;
pa = 24;
pb = 53;
pc = 64;
exa = 128;
exb = 1024;
exc = 16384;
ema = -125;
emb = -1021;
emc = -16381;
a = 1.1920928955078125e-7;
b = 2.220446049250313080847263336181640625e-16;
c = 1.0842022000000000000246549101978293525058043931457636234e-19;
a = 1.17549435082228750796873653722224567781866555677208752151e-38;
b = 2.22507385850720138309023271733240406421921598046233183055e-308;
c = 3.36210310000000000012321085901864782684639798824524059136e-4932;
a = 3.4028234663852885981170418348451692544e+38;
b = 1.79769313486231570814527423731704356798070567525844996599e+308;
c = Inf;
pa = 6;
pb = 15;
pc = 18;
pa = 37;
pb = 307;
pc = 4931;
Note, the Inf above, which is incorrect. I'm looking into the problem.
In float.h, I find
#define LDBL_MAX 1.1897314953572317650E+4932L
I suspect that either
(1) the computation in arith.c, which uses MPFR and round-to-nearest,
may have some rounding issues.
or
(2) whatever spits out the .t0.original is having rounding issues.
--
Steve
program s
integer, parameter :: k4 = 4, k8 = 8, kb = 10
integer ba, bb, bc, pa, pb, pc, exa, exb, exc, ema, emb, emc
real(k4) a
real(k8) b
real(kb) c
!
! Model parameters
!
ba = radix(a)
bb = radix(b)
bc = radix(c)
pa = digits(a)
pb = digits(b)
pc = digits(c)
exa = maxexponent(a)
exb = maxexponent(b)
exc = maxexponent(c)
ema = minexponent(a)
emb = minexponent(b)
emc = minexponent(c)
!
! Things related to the above.
!
a = epsilon(a) ! b**(1-p)
b = epsilon(b)
c = epsilon(c)
a = tiny(a) ! b**(emin - 1)
b = tiny(b)
c = tiny(c)
a = huge(a) ! (1-b(-p))*b**emax
b = huge(b)
c = huge(c)
pa = precision(a) ! int((p-1)*log10(b)) + k such that k = 0 or 1.
pb = precision(b)
pc = precision(c)
pa = range(a) ! int(min(log10(huge), -log10(tiny)))
pb = range(b)
pc = range(c)
end program s