Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!bu.edu!m2c!wpi.WPI.EDU!wpi!aej
From: aej@manyjars.WPI.EDU (Allan E Johannesen)
Newsgroups: comp.lang.fortran
Subject: Re: DEC System 5000 f77 bug
Message-ID: <AEJ.91Jun3105054@manyjars.WPI.EDU>
Date: 3 Jun 91 15:50:54 GMT
References: <1694@usage.csd.unsw.oz.au>
Sender: news@wpi.WPI.EDU (News)
Followup-To: comp.lang.fortran
Organization: Worcester Polytechnic Institute, Worcester, MA 01609-2280
Lines: 42
In-Reply-To: michaelg@hydra.maths.unsw.oz.au's message of 3 Jun 91 04: 12:35 GMT
Nntp-Posting-Host: manyjars.wpi.edu


On 3 Jun 91 04:12:35 GMT,
michaelg@hydra.maths.unsw.oz.au (Michael Gerberg) said:
michaelg> Xref: wpi.WPI.EDU comp.lang.fortran:3870 comp.sys.dec:4946
michaelg> comp.unix.ultrix:7056 Sender: news@usage.csd.unsw.oz.au
michaelg> Followup-To: comp.lang.fortran

michaelg> We have discovered that the -r8 option (single to double
michaelg> precision conversion) of the f77 compiler (Version 2.0) on
michaelg> our DEC Stations 5000 running ULTRIX (Version 4.1) is
michaelg> unusable. The trouble is that certain specific intrinsic
michaelg> functions are not converted to appropriate equivalents. In
michaelg> particular, references to CABS, AMOD, DPROD, AIMAG, CSQRT,
michaelg> CEXP, ALOG, CLOG, ALOG10, CSIN and CCOS produce a compile
michaelg> time error "bad argument type to intrinsic" and references
michaelg> to REAL, FLOAT, SNGL and CMPLX cause run time loss of
michaelg> precision.  This compiler option is rather important to us
michaelg> since manual conversion of old programs can be very time
michaelg> consuming. Unfortunately, DEC people here in Sydney spent a
michaelg> long time trying to persuade us that the bug does not exist
michaelg> and the option performs as intended. That just does not make
michaelg> any sense. We ask other users to help us convince DEC to fix
michaelg> the bug.

I am sorry to say that the bugs you describe exist in version 3.0 (DEC
fortran) as well.  At least I tried CABS and found that it choked on
the CABS conversion in the simple program:

      real x,y
      complex z
      read (5,*) x,y
      z = cmplx(x,y)
      write (6,*) z,cabs(z)
      end

Removing the CABS, so that it would link, I found that you are correct
about the loss of precision across CMPLX also.  I do not know if the
version 3 implementation is exactly as disfunctional as version 2, but
it appears that it has similar failings.

I agree that such a disfunctional -r8 renders the option nearly
useless.