Re: problem with very small numbers - g95 versus gfortran

"e p chandler" <epc8@xxxxxxxx> wrote in message
news:cba2a6c6-2677-42e1-a6a8-8ce070b851c1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Apparently there is a problem with assigning a very small double
precision literal to a 10-byte real. (MinGW on Win32). Assigning a
literal of the proper kind resolves the problem.

Yeah, and FX relates to me that it's not only g95 that can run into
problems with denormals. He gave an example where BOZ
representations of denormals could be converted improperly, but
inconsistently so in gfortran and said that other compilers faced
problems. Likely the problem is that denormals are a special case
so that code where they are handled is not as well tested as the
normal case.

Just for fun, tell me what g95 does with the following:

C:\gcc_mingw64a\test\denormal>type denormal.f90
real*10 x,y

x=1d-306
y=1e-306_10

print *,306,x,y
print '(2(e30.20e4,/))',x,y

x=1d-307
y=1e-307_10

print *,307,x,y
print '(2(e30.20e4,/))',x,y

x=1d-308
y=1e-308_10

print *,308,x,y
print '(2(e30.20e4,/))',x,y

print*, tiny(1.0d0), tiny(1.0e0_10)

x=2.23d-308
y=2.23e-308_10
print*,'tiny+',x,y

print '(2(e30.20e4,/))',x,y
print '(z16.16)', transfer(2.23d-308,0_8)

x=2.22d-308
y=2.22e-308_10
print*,'tiny-',x,y

print '(2(e30.20e4,/))',x,y
print '(z16.16)', transfer(2.22d-308,0_8)

end

C:\gcc_mingw64a\test\denormal>x86_64-pc-mingw32-gfortran
denormal.f90 -odenormal


C:\gcc_mingw64a\test\denormal>denormal
306 1.00000000000000002790E-0306 1.00000000000000000003E-0306
0.10000000000000000279E-0305
0.10000000000000000000E-0305

307 9.99999999999999909327E-0308 1.00000000000000000003E-0307
0.99999999999999990933E-0307
0.10000000000000000000E-0306

308 9.99999999999999909327E-0309 9.99999999999999999974E-0309
0.99999999999999990933E-0308
0.99999999999999999997E-0308

2.22507385850720138E-308 3.36210314311209350626E-4932
tiny+ 2.23000000000000010412E-0308 2.22999999999999999990E-0308
0.22300000000000001041E-0307
0.22299999999999999999E-0307

0010091177587F83
tiny- 2.22000000000000013467E-0308 2.22000000000000000006E-0308
0.22200000000000001347E-0307
0.22200000000000000001E-0307

000FF6A8EBE79958

C:\gcc_mingw64a\test\denormal>gfortran -v
Using built-in specs.
Target: x86_64-pc-mingw32
Configured with:
.../gcc/configure --prefix=/var/tmp/rt --with-sysroot=/var/tmp/r
t --host=i686-pc-mingw32 --target=x86_64-pc-mingw32 -q --silent
Thread model: win32
gcc version 4.4.0 20080523 (experimental) (GCC)

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end


.

Relevant Pages

  • Re: problem with very small numbers - g95 versus gfortran
    ... Yeah, and FX relates to me that it's not only g95 that can run into ... problems with denormals. ... inconsistently so in gfortran and said that other compilers faced ...
    (comp.lang.fortran)
  • Re: generating win32 exe on linux platform
    ... Most likely, though, you have to compile g95 yourself ... about win32 files, though. ... So, the gnu Fortran, gfortran, is capable of being built as a cross compiler, presumably at least for mingw and cygwin targets. ... Maybe g95 as well, by analogy, but it is not covered by your remarks about gnu compilers, as it isn't one. ...
    (comp.lang.fortran)
  • Re: Who is using SBCL on OSX 10.3.2?
    ... I'd forgotten about that win32 bit. ... yeah I noticed you were putting the opengl ng to good use. ... My FFI macros expand into wrapper ... KT> calls to give friendly runtime diagnostics. ...
    (comp.lang.lisp)
  • Re: .NET 3.0
    ... Yeah, same as they are usable from notepad. ... Delphi will have some catching up to do. ... On Win32, it doesn't. ...
    (borland.public.delphi.non-technical)
  • Re: generating win32 exe on linux platform
    ... using win32 version of g95 under wine? ... The GNU compilers, in general, are designed to be used as cross ... Most likely, though, you have to compile g95 yourself ... about win32 files, though. ...
    (comp.lang.fortran)