pla@zippy.eecs.umich.edu (Paul Anderson) (11/30/87)
We get this output from the following program:
$ test.bin
1.0000000000000000E-99
***********************
1.0000000000000000-101
$
Where test.ftn is:
read*8 x
x = 1.0e-99
write(6,*) x
x = 1.0e-100
write(6,*) x
x = 1.0e-101
write(6,*) x
end
We are running sr9.6, but we've had this problem
for the last few releases. Any ideas?
Note that we get problems only with an exponent of E-100.
Perhaps there is some kind of overflow problem, but I'd
like to know if it is my fault or the ftnlib's fault.
Thanks...
Paul Anderson
University of Michigan EECS deptSHULL@WHARTON.UPENN.EDU (12/02/87)
Paul Anderson (umix!umich!pla@nrl-cmf.arpa) writes: > We get this output from the following program: > > $ test.bin > 1.0000000000000000E-99 > *********************** > 1.0000000000000000-101 > $ > > Where test.ftn is: > > read*8 x > x = 1.0e-99 > write(6,*) x > x = 1.0e-100 > write(6,*) x > x = 1.0e-101 > write(6,*) x > end > Sorry Paul, but after converting your tabs to spaces, and your "read*8" to a "real*8", I got the following, correct result: $ catf t.ftn real*8 x x = 1.0e-99 write(6,*) x x = 1.0e-100 write(6,*) x x = 1.0e-101 write(6,*) x end $ ftn t;t.bin no errors, no warnings in $MAIN, Fortran version 9.36 1987/12/01 17:58:57 EDT (Tue) 1.0000000000000000E-99 1.0000000000000000-100 1.0000000000000000-101 Fortran STOP $ By the way, I am also running SR9.5.1 and an "early SR9.6" FTN: $ ftn -version ftn (Fortran 77 Compiler), revision 9.36 (the 9.6 ftn is: $ ftn -version ftn (Fortran 77 Compiler), revision 9.38 ) Best of luck! -Chris Christopher E. Shull Decision Sciences Department The Wharton School shull@wharton.upenn.edu University of Pennsylvania Philadelphia, PA 19104-6366 215/898-5930 If it ain't broke, don't fix it!
krowitz@mit-richter.UUCP (David Krowitz) (12/02/87)
Hmm ... I tried the same program on my system and found that it worked fine (with the real*8 typo fixed) under SR9.5.1 and that the bug *was* present under SR9.6. It didn't matter which compiler was used to compile the program, only which version of AEGIS was running on the node which executed the program. The problem is in the runtime library for SR9.6. I should probably mention that I tested this only on a DN3000 running SR9.6 -- David Krowitz mit-erl!mit-kermit!krowitz@eddie.mit.edu mit-erl!mit-kermit!krowitz@mit-eddie.arpa krowitz@mit-mc.arpa (in order of decreasing preference)
pla@zippy.eecs.umich.edu (Paul Anderson) (12/02/87)
In article <8712020018.AA07339@EDDIE.MIT.EDU> krowitz@mit-richter.UUCP (David Krowitz) writes: >Hmm ... I tried the same program on my system and found >that it worked fine (with the real*8 typo fixed) under >SR9.5.1 and that the bug *was* present under SR9.6. It >didn't matter which compiler was used to compile the >program, only which version of AEGIS was running on the >node which executed the program. The problem is in >the runtime library for SR9.6. I should probably mention >that I tested this only on a DN3000 running SR9.6 > > > -- David Krowitz > Sorry for the typo, gang... I had to type it by hand through a vt100 emulator to another system. Since we have bunchloads of systems here at UM, I tried the program on a number of machines. It seems to be related to different /lib/ftnlib's rather than the compilers. Machine Release of FTNLIB Works? DSP90 SR9.2.3 yup (was compiled w/ftn version 8.40) DN3000 SR9.5.1 yup (all others with ftn 9.38) DN460 SR9.5.1 yup DN560 SR9.6 nope DN3000 SR9.6 nope DN330 SR9.6 nope Looks like a problem, all right, though it is kinda small. Paul Anderson