Conference turris::fortran

1189.0. "Alpha and FLTINV..." by PRSSOS::DEGAGE () Thu Feb 20 1997 05:32

	Hello,

	Following is a little source program, which gives,as for me, not such
a good example of what can be done with Fortran language...

THis program is OK on VAX platform, Sun, HP... but not on Alpha : my opinion
is that we encounter "dirty zeros" problem.

Then , the solutions :

1) modify the code to clean-up the dirty zeros values
   ---> Impossible for the customer because the Integer values should remain
        in memory ( and not be forced to zero)

2) introduce a condtion handler to handle HPARITH error and continue when
   a FLTINV error is detected
   ---> the code must be modified and it is very heavy for the customer
        because the source size is huge...


Then I have got no more idea.
So please, can you say me if my diagnostic is OK ?
then is there another solution for them ( whithout modifying the code ??)

Thanks a lot.

Marielle Degage  CSC France

      common /val/b(6)   
      dimension adat(6,2)

      call charge
           print 10,(' charge  ', n,b(n),b(n) ,n=1,6)
      do ll=1,2
        do n=1,6
          adat(n,ll)=b(n)
        enddo
      enddo
      do  n=1,6
         if ( adat(n,1).ne.adat(n,2)) then
            print 10,' inegal', n,adat(n,1),adat(n,1)
         else
            print 10,' egal  ', n,adat(n,1),adat(n,1)
         endif
  10  format(a, i5,z12,5x,e15.6)
      enddo 
       stop
      end
      subroutine charge
      common /val/a(3),ia(3)   
      do i=1,3
        a(i)=i
       ia(i)=i*1.
      enddo
      print *,' ia ',ia
      print *,'  a ',a

      return
      end

ia            1           2           3
  a    1.000000       2.000000       3.000000
charge      1        4080        0.100000E+01
charge      2        4100        0.200000E+01
charge      3        4140        0.300000E+01
charge      4           1        0.000000E+00
charge      5           2        0.000000E+00
charge      6           3        0.000000E+00
egal      1        4080        0.100000E+01
egal      2        4100        0.200000E+01
egal      3        4140        0.300000E+01
%SYSTEM-F-HPARITH, high performance arithmetic trap, Imask=00000000,
Fmask=00000
002, summary=02, PC=000301AC, PS=0000001B
-SYSTEM-F-FLTINV, floating invalid operation, PC=000301AC, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
 Image Name   Module Name     Routine Name    Line Number  rel PC      abs PC
 ORI_BRIARD   ORI_BRIARD$MAIN ORI_BRIARD$MAIN          12 000001AC    000301AC
                                                        0 82E1C170    82E1C170

You are right that this is "not such a good example" - it is clearly
illegal Fortran.  But you can make it work by compiling with
/FLOAT=IEEE/IEEE_MODE=UNDERFLOW_TO_ZERO.   On Sun and HP, you get IEEE floating
with denorms accepted, so the program "runs" (but possibly gives wrong
answers - I wonder what the real application does with this.)

					Steve

The correct solution is to declare b and adat to be integers, or to
declare an integer equivalenced to each of them:

      common /val/b(6)   
	integer ib(6)
	equivalence (ib,b)
      dimension adat(6,2)
	integer idat(6,2)
	equivalence (idat,adat)

      do  n=1,6
         if ( idat(n,1).ne.idat(n,2)) then
            print 10,' inegal', n,idat(n,1),idat(n,1)
         else
            print 10,' egal  ', n,idat(n,1),idat(n,1)
         endif

On the Sun and HP systems, if you change the subroutine to store negative
numbers, you'll get a surprise -- the negative integers won't appear to be
equal.

      do i=1,3
        a(i)=-i
       ia(i)=-i*1.
      enddo

To get the same results on Alpha as you get on Sun and HP, compile with
/FLOAT=IEEE/IEEE=DENORM

	Thanks a lot for your answers.
My customer acknowledged the "illegality" of the code...but needs such
strange datas to make simulations...

They will use IEEE mode.
Marielle

I think /IEEE_MODE=UNDERFLOW_TO_ZERO is better than DENORM in this case -
it will slow down the code less and should not affect the results.

				Steve