problem with very small numbers - g95 versus gfortran 
Author Message
 problem with very small numbers - g95 versus gfortran

This is related to a different thread in which the OP claimed that
numbers set to 0 were being displayed as approx. e-309.

While playing with numbers in this range, I encountered what appears
to be a bug in g95. (See Google's gg95)

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.

Of course I realize that assigning a real constant to a double
precision variable, etc. may result in loss of precision, but in this
case it seems more like a real error. It looks like a bit gets dropped
near 1e-308.

Program listing:

C:\temp>type x.f95
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

end

Output:

C:\temp>g95 x.f95

C:\temp>a
 306 1.0000000000000000279E-306 1.E-306
  0.10000000000000000279E-0305
  0.10000000000000000000E-0305

 307 9.999999999999999093E-308 1.E-307
  0.99999999999999990933E-0307
  0.10000000000000000000E-0306

 308 4.9999999999999995466E-309 1.E-308
  0.49999999999999995466E-0308
  0.99999999999999999997E-0308

C:\temp>gfortran x.f95

C:\temp>a
         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

Versions:

C:\temp>g95 -v
Using built-in specs.
Target:
Configured with: /src/G95/gcc-4.1.2/configure --prefix=/mingw --enable-
languages
=c --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --host=i386-pc-
mingw32 --enab
le-threads --disable-nls --disable-win32-registry --enable-sjlj-
exceptions --ena
ble-libgcj --without-x
Thread model: win32
gcc version 4.1.2 (g95 0.92!) May 15 2008

C:\temp>gfortran -v
Using built-in specs.
Target: i586-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw --enable-
languages=c,fortran
 --with-gmp=/home/FX/local --with-ld=/mingw/bin/ld --with-as=/mingw/
bin/as --dis
able-werror --enable-bootstrap --enable-threads --disable-nls --
build=i586-pc-mi
ngw32 --enable-libgomp --disable-shared
Thread model: win32
gcc version 4.4.0 20080514 (experimental) [trunk revision 135286]
(GCC)

- e



Mon, 15 Nov 2010 01:53:16 GMT  
 problem with very small numbers - g95 versus gfortran


Quote:
> 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



Mon, 15 Nov 2010 09:43:52 GMT  
 problem with very small numbers - g95 versus gfortran


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

And for even more fun, this experiment tempting overflow:

C:\gcc_mingw64a\test\denormal>type mega.f90
program mega
   real(4) x4
   real(8) x8
   real(10) x10
   real pi

   pi = 4*atan(1.0)

   x4 = 2
   x4 = log(huge(x4))+log(x4)*1.1
   write(*,*) cos(complex(pi/4,x4))
   x4 = log(huge(x4))
   write(*,*) cos(complex(pi/4,x4))

   x8 = 2
   x8 = log(huge(x8))+log(x8)*1.1
   write(*,*) cos(complex(pi/4,x8))
   x8 = log(huge(x8))
   write(*,*) cos(complex(pi/4,x8))

   x10 = 2
   x10 = log(huge(x10))+log(x10)*1.1
   write(*,*) cos(complex(pi/4,x10))
   x10 = log(huge(x10))
   write(*,*) cos(complex(pi/4,x10))
   write(*,*) huge(x4)
   write(*,*) huge(x8)
   write(*,*) huge(x10)
end program mega

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

C:\gcc_mingw64a\test\denormal>mega
 (      +Infinity,      -Infinity)
 ( 1.20308013E+38,-1.20308013E+38)
 (                +Infinity,                -Infinity)
 ( 6.35580489185754273E+307,-6.35580516967861561E+307)
 (                    +Infinity,                    -Infinity)
 ( 4.20633594885755398476E+4931,-4.20633613272234874657E+4931)
  3.40282347E+38
  1.79769313486231571E+308
  1.18973149535723176502E+4932

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



Mon, 15 Nov 2010 11:01:02 GMT  
 problem with very small numbers - g95 versus gfortran

Quote:

> > 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

OK. Here is the run with g95:

C:\Users\epc\temp>g95 denormal.f90

C:\Users\epc\temp>a
 306 1.0000000000000000279E-306 1.E-306
  0.10000000000000000279E-0305
  0.10000000000000000000E-0305

 307 9.999999999999999093E-308 1.E-307
  0.99999999999999990933E-0307
  0.10000000000000000000E-0306

 308 4.9999999999999995466E-309 1.E-308
  0.49999999999999995466E-0308
  0.99999999999999999997E-0308

 2.2250738585072014E-308 3.3621031431120935063E-4932
 tiny+ 2.230000000000000104E-308 2.23E-308
  0.22300000000000001041E-0307
  0.22299999999999999999E-0307

0010091177587F83
 tiny- 1.11000000000000006733E-308 2.22E-308
  0.11100000000000000673E-0307
  0.22200000000000000001E-0307

000FF6A8EBE79958

C:\Users\epc\temp>

Looking up TINY() shows:

TINY(X) returns the smallest positive (non zero) number in the model
of the type of X.

Please explain what I am seeing in light of the above definition. Does
this mean that specifying a literal in double precision where that
literal is less than tiny() is invalid? Yet it seems to work with
gfortran.

At least you found the boundary where the bug is triggered.

- e



Mon, 15 Nov 2010 11:12:25 GMT  
 problem with very small numbers - g95 versus gfortran


Quote:

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

> And for even more fun, this experiment tempting overflow:

> C:\gcc_mingw64a\test\denormal>type mega.f90
> program mega
> ? ?real(4) x4
> ? ?real(8) x8
> ? ?real(10) x10
> ? ?real pi

> ? ?pi = 4*atan(1.0)

> ? ?x4 = 2
> ? ?x4 = log(huge(x4))+log(x4)*1.1
> ? ?write(*,*) cos(complex(pi/4,x4))
> ? ?x4 = log(huge(x4))
> ? ?write(*,*) cos(complex(pi/4,x4))

> ? ?x8 = 2
> ? ?x8 = log(huge(x8))+log(x8)*1.1
> ? ?write(*,*) cos(complex(pi/4,x8))
> ? ?x8 = log(huge(x8))
> ? ?write(*,*) cos(complex(pi/4,x8))

> ? ?x10 = 2
> ? ?x10 = log(huge(x10))+log(x10)*1.1
> ? ?write(*,*) cos(complex(pi/4,x10))
> ? ?x10 = log(huge(x10))
> ? ?write(*,*) cos(complex(pi/4,x10))
> ? ?write(*,*) huge(x4)
> ? ?write(*,*) huge(x8)
> ? ?write(*,*) huge(x10)
> end program mega

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

> C:\gcc_mingw64a\test\denormal>mega
> ?( ? ? ?+Infinity, ? ? ?-Infinity)
> ?( 1.20308013E+38,-1.20308013E+38)
> ?( ? ? ? ? ? ? ? ?+Infinity, ? ? ? ? ? ? ? ?-Infinity)
> ?( 6.35580489185754273E+307,-6.35580516967861561E+307)
> ?( ? ? ? ? ? ? ? ? ? ?+Infinity, ? ? ? ? ? ? ? ? ? ?-Infinity)
> ?( 4.20633594885755398476E+4931,-4.20633613272234874657E+4931)
> ? 3.40282347E+38
> ? 1.79769313486231571E+308
> ? 1.18973149535723176502E+4932

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

OK. Here it goes on g95:

C:\Users\epc\temp>g95 mega.f90
In file mega.f90:25

   write(*,*) cos(complex(pi/4,x10))
                               1
In file mega.f90:19

   write(*,*) cos(complex(pi/4,x8))
                               2
Warning (155): Inconsistent types (REAL(10)/REAL(8)) in actual
argument lists at
 (1) and (2)
In file mega.f90:25

   write(*,*) cos(complex(pi/4,x10))
                               1
In file mega.f90:17

   write(*,*) cos(complex(pi/4,x8))
                               2
Warning (155): Inconsistent types (REAL(10)/REAL(8)) in actual
argument lists at
 (1) and (2)
In file mega.f90:25

   write(*,*) cos(complex(pi/4,x10))
                               1
In file mega.f90:13

   write(*,*) cos(complex(pi/4,x4))
                               2
Warning (155): Inconsistent types (REAL(10)/REAL(4)) in actual
argument lists at
 (1) and (2)
In file mega.f90:25

   write(*,*) cos(complex(pi/4,x10))
                               1
In file mega.f90:11

   write(*,*) cos(complex(pi/4,x4))
                               2
Warning (155): Inconsistent types (REAL(10)/REAL(4)) in actual
argument lists at
 (1) and (2)
C:\Users\epc\AppData\Local\Temp/ccErGX8Q.o:mega.f90:(.text+0xb0):
undefined refe
rence to `complex_'
C:\Users\epc\AppData\Local\Temp/ccErGX8Q.o:mega.f90:(.text+0x164):
undefined ref
erence to `complex_'
C:\Users\epc\AppData\Local\Temp/ccErGX8Q.o:mega.f90:(.text+0x252):
undefined ref
erence to `complex_'
C:\Users\epc\AppData\Local\Temp/ccErGX8Q.o:mega.f90:(.text+0x311):
undefined ref
erence to `complex_'
C:\Users\epc\AppData\Local\Temp/ccErGX8Q.o:mega.f90:(.text+0x403):
undefined ref
erence to `complex_'
C:\Users\epc\AppData\Local\Temp/ccErGX8Q.o:mega.f90:(.text+0x4cd):
more undefine
d references to `complex_' follow

C:\Users\epc\temp>

??????????

- e



Mon, 15 Nov 2010 11:21:06 GMT  
 problem with very small numbers - g95 versus gfortran


Quote:
> C:\Users\epc\AppData\Local\Temp/ccErGX8Q.o:mega.f90:(.text+0xb0):
> undefined refe
> rence to `complex_'

Oops.  The COMPLEX intrinsic was a Craig Burley original, not
carried forward to g95.  Here is the standard-conforming variant:

C:\gcc_mingw64a\test\denormal>type mega.f90
program mega
   real(4) x4
   real(8) x8
   real(10) x10
   real pi

   pi = 4*atan(1.0)

   x4 = 2
   x4 = log(huge(x4))+log(x4)*1.1
   write(*,*) cos(cmplx(pi/4,x4,kind(x4)))
   x4 = log(huge(x4))
   write(*,*) cos(cmplx(pi/4,x4,kind(x4)))

   x8 = 2
   x8 = log(huge(x8))+log(x8)*1.1
   write(*,*) cos(cmplx(pi/4,x8,kind(x8)))
   x8 = log(huge(x8))
   write(*,*) cos(cmplx(pi/4,x8,kind(x8)))

   x10 = 2
   x10 = log(huge(x10))+log(x10)*1.1
   write(*,*) cos(cmplx(pi/4,x10,kind(x10)))
   x10 = log(huge(x10))
   write(*,*) cos(cmplx(pi/4,x10,kind(x10)))
   write(*,*) huge(x4)
   write(*,*) huge(x8)
   write(*,*) huge(x10)
end program mega

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

C:\gcc_mingw64a\test\denormal>mega
 (      +Infinity,      -Infinity)
 ( 1.20308013E+38,-1.20308013E+38)
 (                +Infinity,                -Infinity)
 ( 6.35580489185754273E+307,-6.35580516967861561E+307)
 (                    +Infinity,                    -Infinity)
 ( 4.20633594885755398476E+4931,-4.20633613272234874657E+4931)
  3.40282347E+38
  1.79769313486231571E+308
  1.18973149535723176502E+4932

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



Mon, 15 Nov 2010 11:52:00 GMT  
 problem with very small numbers - g95 versus gfortran


Quote:
> Looking up TINY() shows:
> TINY(X) returns the smallest positive (non zero) number in the model
> of the type of X.
> Please explain what I am seeing in light of the above definition. Does
> this mean that specifying a literal in double precision where that
> literal is less than tiny() is invalid? Yet it seems to work with
> gfortran.
> At least you found the boundary where the bug is triggered.

I don't have much time, but a description of denormals might perhaps
be found in http://download.intel.com/design/processor/manuals/253665.pdf
section 4.8.3.2.  Suffice it to say that denormals aren't model
numbers.

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



Mon, 15 Nov 2010 11:58:10 GMT  
 problem with very small numbers - g95 versus gfortran


Quote:

> > C:\Users\epc\AppData\Local\Temp/ccErGX8Q.o:mega.f90:(.text+0xb0):
> > undefined refe
> > rence to `complex_'

> Oops. ?The COMPLEX intrinsic was a Craig Burley original, not
> carried forward to g95. ?Here is the standard-conforming variant:

> C:\gcc_mingw64a\test\denormal>type mega.f90
> program mega
> ? ?real(4) x4
> ? ?real(8) x8
> ? ?real(10) x10
> ? ?real pi

> ? ?pi = 4*atan(1.0)

> ? ?x4 = 2
> ? ?x4 = log(huge(x4))+log(x4)*1.1
> ? ?write(*,*) cos(cmplx(pi/4,x4,kind(x4)))
> ? ?x4 = log(huge(x4))
> ? ?write(*,*) cos(cmplx(pi/4,x4,kind(x4)))

> ? ?x8 = 2
> ? ?x8 = log(huge(x8))+log(x8)*1.1
> ? ?write(*,*) cos(cmplx(pi/4,x8,kind(x8)))
> ? ?x8 = log(huge(x8))
> ? ?write(*,*) cos(cmplx(pi/4,x8,kind(x8)))

> ? ?x10 = 2
> ? ?x10 = log(huge(x10))+log(x10)*1.1
> ? ?write(*,*) cos(cmplx(pi/4,x10,kind(x10)))
> ? ?x10 = log(huge(x10))
> ? ?write(*,*) cos(cmplx(pi/4,x10,kind(x10)))
> ? ?write(*,*) huge(x4)
> ? ?write(*,*) huge(x8)
> ? ?write(*,*) huge(x10)
> end program mega

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

> C:\gcc_mingw64a\test\denormal>mega
> ?( ? ? ?+Infinity, ? ? ?-Infinity)
> ?( 1.20308013E+38,-1.20308013E+38)
> ?( ? ? ? ? ? ? ? ?+Infinity, ? ? ? ? ? ? ? ?-Infinity)
> ?( 6.35580489185754273E+307,-6.35580516967861561E+307)
> ?( ? ? ? ? ? ? ? ? ? ?+Infinity, ? ? ? ? ? ? ? ? ? ?-Infinity)
> ?( 4.20633594885755398476E+4931,-4.20633613272234874657E+4931)
> ? 3.40282347E+38
> ? 1.79769313486231571E+308
> ? 1.18973149535723176502E+4932

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

OK. Here it goes with G95:

C:\Users\epc\temp>g95 mega.f90

C:\Users\epc\temp>a
 (2.5788508E+38,-2.5788508E+38)
 (1.2030801E+38,-1.2030801E+38)
 (+Inf,-Inf)
 (6.355804891857543E+307,-6.355805169678616E+307)
 (+Inf,-Inf)
 (4.2063359488591517347E+4931,-4.2063361327239468925E+4931)
 3.4028235E+38
 1.7976931348623157E+308
 1.189731495357231765E+4932

C:\Users\epc\temp>

- e



Mon, 15 Nov 2010 12:23:04 GMT  
 problem with very small numbers - g95 versus gfortran


Quote:

> > Looking up TINY() shows:
> > TINY(X) returns the smallest positive (non zero) number in the model
> > of the type of X.
> > Please explain what I am seeing in light of the above definition. Does
> > this mean that specifying a literal in double precision where that
> > literal is less than tiny() is invalid? Yet it seems to work with
> > gfortran.
> > At least you found the boundary where the bug is triggered.

> I don't have much time, but a description of denormals might perhaps
> be found inhttp://download.intel.com/design/processor/manuals/253665.pdf
> section 4.8.3.2. ?Suffice it to say that denormals aren't model
> numbers.

1. MR&C [p. 166] says "Note that is quite likely that there are some
machine numbers that lie outside the model." It then mentions
denormals.

2. Thanks for the Intel reference.

3. I really do like MR&C, but it's quite terse. I think I need a book
entitled "fortran 95/2003 explained explained".

- e



Mon, 15 Nov 2010 13:09:27 GMT  
 problem with very small numbers - g95 versus gfortran


Quote:
> OK. Here it goes with G95:
> C:\Users\epc\temp>g95 mega.f90
> C:\Users\epc\temp>a
>  (2.5788508E+38,-2.5788508E+38)
>  (1.2030801E+38,-1.2030801E+38)
>  (+Inf,-Inf)
>  (6.355804891857543E+307,-6.355805169678616E+307)
>  (+Inf,-Inf)
>  (4.2063359488591517347E+4931,-4.2063361327239468925E+4931)
>  3.4028235E+38
>  1.7976931348623157E+308
>  1.189731495357231765E+4932

I have worried about writing a replacement for missing intrinsics
because if you're not careful intermediate calculations may
overflow even though the final result should be a model number.
I suppose I need not have worried so much considering that at
least for gcc-based compilers this kind of care is not taken for
the intrinsics in the first place.  I speculate that you didn't
overflow for the single precision version because the single
precision overflow intermediate was never stored into memory
as a single precision number.  In the x86_64 compilers the
computation is more likely to be carried out in SSE registers
where single-precision overflow really is overflow; there is no
15-bit exponent field in the xmm registers as there is in x87
registers.

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



Mon, 15 Nov 2010 14:08:01 GMT  
 problem with very small numbers - g95 versus gfortran


Quote:
> 2. Thanks for the Intel reference.

It was needlessly hard to find because Intel's web page changed to
something so horrible it's like an act of vandalism.  Has my
computer gotten infected by adware/spyware or did Intel really do this?

Quote:
> 3. I really do like MR&C, but it's quite terse. I think I need a book
> entitled "fortran 95/2003 explained explained".

The f03 standard, N1601.pdf, and your fine compiler manual (gfortran's
has been getting some upgrades of late) are good companions.  The
terseness makes it possible to kind of skim through the book in
a day or two so that you can know roughly what the capabilities of
the language are and also approximately where they are in MR&C.
F03 has so much in it that even the MR&C take on it isn't all
that terse.

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



Mon, 15 Nov 2010 14:16:05 GMT  
 problem with very small numbers - g95 versus gfortran


Quote:


>> OK. Here it goes with G95:

>> C:\Users\epc\temp>g95 mega.f90

>> C:\Users\epc\temp>a
>>  (2.5788508E+38,-2.5788508E+38)
>>  (1.2030801E+38,-1.2030801E+38)
>>  (+Inf,-Inf)
>>  (6.355804891857543E+307,-6.355805169678616E+307)
>>  (+Inf,-Inf)
>>  (4.2063359488591517347E+4931,-4.2063361327239468925E+4931)
>>  3.4028235E+38
>>  1.7976931348623157E+308
>>  1.189731495357231765E+4932

> I have worried about writing a replacement for missing intrinsics
> because if you're not careful intermediate calculations may
> overflow even though the final result should be a model number.
> I suppose I need not have worried so much considering that at
> least for gcc-based compilers this kind of care is not taken for
> the intrinsics in the first place.  I speculate that you didn't
> overflow for the single precision version because the single
> precision overflow intermediate was never stored into memory
> as a single precision number.  In the x86_64 compilers the
> computation is more likely to be carried out in SSE registers
> where single-precision overflow really is overflow; there is no
> 15-bit exponent field in the xmm registers as there is in x87
> registers.

Please read about -ffloat-store.

--
Steve
http://troutmask.apl.washington.edu/~kargl/



Mon, 15 Nov 2010 14:20:37 GMT  
 problem with very small numbers - g95 versus gfortran


Quote:
> Please read about -ffloat-store.

You mean:

http://gcc.gnu.org/onlinedocs/gcc/Disappointments.html#index-ffloat_0...

? :)  Well, OK:

http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-ffloat_...

but how should this have any effect in the current case?  Don't
all compilers in question issue calls to _ccosf, _ccos, and _ccosl
so that a compiler option won't affect the outcome?  The overflow,
if it happens, does so after the invocation of the library
function and before its return as the result is in range for a
model number in all cases.

Now, if you really want to see some difference, consider what
happens when we do the same with initialization expressions so that
gfortran uses mpfr rather than the above library functions:

C:\gcc_mingw64a\test\denormal>type mega2.f90
program mega2
   implicit none
   real(4), parameter :: pi = 4*atan(1.0)
   real(4), parameter :: a4 = 2
   real(4), parameter :: b4 = log(huge(a4))+log(a4)*1.1
   complex(4), parameter :: c4 = cmplx(pi/4,b4,kind(c4))
   complex(4), parameter :: x4 = cos(c4)
   integer(kind(1)+int(1/x4)) i4
   real(8), parameter :: a8 = 2
   real(8), parameter :: b8 = log(huge(a8))+log(a8)*1.1
   complex(8), parameter :: c8 = cmplx(pi/4,b8,kind(c8))
   complex(8), parameter :: x8 = cos(c8)
   integer(kind(1)+int(1/x8)) i8
   real(10), parameter :: a10 = 2
   real(10), parameter :: b10 = log(huge(a10))+log(a10)*1.1
   complex(10), parameter :: c10 = cmplx(pi/4,b10,kind(c10))
   complex(10), parameter :: x10 = cos(c10)
   integer(kind(1)+int(1/x10)) i10

   write(*,*) x4
   write(*,*) kind(i4)
   write(*,*) x8
   write(*,*) kind(i8)
   write(*,*) x10
   write(*,*) kind(i10)
end program mega2

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

C:\gcc_mingw64a\test\denormal>mega2
 ( 2.57885078E+38,-2.57885078E+38)
           4
 ( 1.36239662574516360E+308,-1.36239668529741519E+308)
           4
 ( 9.01647863800489008786E+4931,-9.01647903212771289082E+4931)
           4

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



Mon, 15 Nov 2010 15:12:19 GMT  
 
 [ 13 post ] 

 Relevant Pages 

1. g95 versus gfortran

2. g95 AND gfortran problem ONLY on PPC OSX Tiger

3. automatic arrays with negative size in g95 and gfortran

4. Common statement does not work with gfortran, but g95 gives the correct answer

5. gfortran or g95

6. gfortran vs. g95

7. difference between g95 and gfortran

8. Compiler flags for compiling FEM2DLiB with g95 and/or gfortran

9. gfortran, g95, and dual-core

10. Gfortran 2 years behind G95 and still not ready for prime time

11. Vector instruction support in G95 or Gfortran?

12. recl on g95 and gfortran

 

 
Powered by phpBB® Forum Software