Conference turris::fortran

1155.0. "DFAO 4.1: forrtl: error (65): floating invalid" by MGOF01::HSIMON () Fri Jan 31 1997 08:46

Our customer has a problem with floating invalid. In the case
of underflow the program should run with the solution 0.0.

I wrote to the customer:

   There are only two solutions:

           - You increase your variables to 16 bits min. and
             use the corresponding functions (gexp).

           - You do not use the math fast library.

   Reason:
   With the math fast library, the function F_exp() is used instead of
   exp(). The function exp () conforms to IEEE. F_exp() does not support
   IEEE. The FPE (floating point exception) cannot be suppressed!
   This applies to fortran and c.

The customer replied:

   Many thanks for your message. My problem occurs with an ab initio
   package (GAUSSIAN 94). This package is a standard package for this kind
   of calculations and is used for quantum chemistry all over the world. I
   have run nearly all available tests on the ALPHA 500/400. The only
   problem is the floating point exception. This program consists of a
   source code of approx. 500 000 lines from fortran and c programs. Using
   equivalence statements in fortran and memory allocation statements in C
   prevents converting to and testing on Real*16, at least in my case. If
   you do not use the -fast option the program speed is reduced by factor
   2, approximately. This is certainly not what DEC wants, since it is just
   the -fast option which makes full use of the machine. The error should
   not occur at all. A look at signal 8 shows that the occurring floating
   underflow is set to 0.0d0, as described in the man. Therefore
   I'd like to ask you to forward this problem to your Engineering.
 
I reproduce the problem on:

   dunix 4.0A (Rev. 464)
   DFABASE410           installed  Digital Fortran 77 V4.1 for Digital UNIX Alpha Systems
   DFACOM410            installed  Digital Fortran V4.1 Tools & their Man Pages
   DFADOC410            installed  Digital Fortran 77 V4.1 Release Notes and Man Page
   DFARTL373            installed  Digital Fortran RTL #373 for Digital UNIX Alpha (f77 only)
   DFARTL374            installed  Digital Fortran RTL #374 for Digital UNIX Alpha (f90 and f77)
   F9ABASE410           installed  Digital Fortran 90 V4.1 for Digital UNIX Systems
   F9ADOC410            installed  Digital Fortran 90 V4.1 for Digital UNIX Release Notes and Man Page
   PSESHPF107           installed  High Performance Fortran Scalar Libraries

The following little program shows the exception.

Any hints?

Hans-Werner

------------------------------------------------------
Makefile:
FOPT = -g -i8 -r8 -align dcommons -tune host -threads
MOPT = -g3 -math_library fast
#MOPT =  -math_library

all: tst1a tst1b tst2

tst1a: tst1.f
        f77 $(FOPT) $(MOPT) -o tst1a tst1.f

tst1b: tst1.f
        f77 $(FOPT) -o tst1b tst1.f3
------------------------------------------------------
tst1.f:
        program tst1
        implicit real*8(a-h,o-z)
        f=-708.0d0
        do i=1,16
                write(6,*)f,exp(f)
                f=f-0.2d0
        enddo
        end
%

   Note 1027.0 seems relevant in this case. Looks like an RTL bug
   in the fast version of dexp() when handling cases near the underflow
   boundary.

   Both test programs work fine on my Unix 3.2b system.

   (FWIW: The makefile specifies -g (debug info). Does the user realize
   that specifying -g will turn off optimizations, unless an -O level is
   explicitly specified?)

   -- John Faricelli

Yes, it looks like #1027... the program fails on UNIX v4.0 with

  -708.000000000000       3.307553003638408E-308
  -708.200000000000       2.707995361514092E-308
  -708.400000000000       0.000000000000000E+000
  -708.600000000000       0.000000000000000E+000
  -708.800000000000       0.000000000000000E+000
  -709.000000000000       0.000000000000000E+000
forrtl: error (65): floating invalid

but works fine on UNIX v3.2

  -708.000000000000       3.307553003638407E-308
  -708.200000000000       2.707995361514092E-308
  -708.400000000000       0.000000000000000E+000
  -708.600000000000       0.000000000000000E+000
  -708.800000000000       0.000000000000000E+000
  -709.000000000000       0.000000000000000E+000
  -709.200000000000       0.000000000000000E+000
  -709.400000000000       0.000000000000000E+000
  -709.600000000000       0.000000000000000E+000
  -709.800000000000       0.000000000000000E+000
  -710.000000000000       0.000000000000000E+000
  -710.200000000001       0.000000000000000E+000
  -710.400000000001       0.000000000000000E+000
  -710.600000000001       0.000000000000000E+000
  -710.800000000001       0.000000000000000E+000
  -711.000000000001       0.000000000000000E+000

I'll ask about the status of this.

/Stan

>> open OSF QAR 51332

A new QAR... I bet they send it to Fortran because the QAR has the letters
F, O, R, T, R, A, and N in some combination in it!

The DPML project leader says that this was a bug in libm that was fixed.  He's
tracking down the fix and the patch now.  Someone will report them here when
he finds them.

/Stan

>A new QAR... I bet they send it to Fortran because the QAR has the letters
>F, O, R, T, R, A, and N in some combination in it!

Nah, the QAR will probably say that they are linking it with some Fortran
library and it will get assigned to the linker group because our name showed
up first in the sentence.   :-)

>>Nah, the QAR will probably say that they are linking it with some Fortran
>>library and it will get assigned to the linker group because our name showed
>>up first in the sentence.   :-)

I wish "LINK" had shown up in the first sentence but no:

	DFAO 4.1: forrtl: error (65): floating invalid

	Our customer has a problem with floating invalid. In the case
	of underflow the program should run with the solution 0.0.

	See fortran note 1155

I'll have this reclassified to the math library and tell OSF_QAR that the claim
is that it's already fixed.

Sigh!			/Stan

    Now can "we" figure out how to deliver a solution to the customer?
    /Rich