michaelg@hydra.maths.unsw.oz.au (Michael Gerberg) (06/03/91)
We have discovered that the -r8 option (single to double precision conversion) of the f77 compiler (Version 2.0) on our DEC Stations 5000 running ULTRIX (Version 4.1) is unusable. The trouble is that certain specific intrinsic functions are not converted to appropriate equivalents. In particular, references to CABS, AMOD, DPROD, AIMAG, CSQRT, CEXP, ALOG, CLOG, ALOG10, CSIN and CCOS produce a compile time error "bad argument type to intrinsic" and references to REAL, FLOAT, SNGL and CMPLX cause run time loss of precision. This compiler option is rather important to us since manual conversion of old programs can be very time consuming. Unfortunately, DEC people here in Sydney spent a long time trying to persuade us that the bug does not exist and the option performs as intended. That just does not make any sense. We ask other users to help us convince DEC to fix the bug. Michael Gerberg School of Mathematics University of New South Wales Sydney, Australia
dik@cwi.nl (Dik T. Winter) (06/03/91)
In article <1694@usage.csd.unsw.oz.au> michaelg@hydra.maths.unsw.oz.au (Michael Gerberg) writes: > The trouble is that certain specific intrinsic > functions are not converted to appropriate equivalents. In particular, > references to CABS, AMOD, DPROD, AIMAG, CSQRT, CEXP, ALOG, CLOG, ALOG10, CSIN > and CCOS produce a compile time error "bad argument type to intrinsic" and > references to REAL, FLOAT, SNGL and CMPLX cause run time loss of precision. I would agree with the error message if you use specific function names, but not with generic names. Now CABS, AMOD etc. are all specific, replacing those by the generic names ABS, MOD etc. would solve the problem. I think the bug is only with REAL and CMPLX, because I think both are generic names. Of course, this does not help if you get code you will run; but than the problem remains with other library (non-instrinsic) routines (eg, BLAS SAXPY etc.). Some change of source is required anyhow. -- dik t. winter, cwi, amsterdam, nederland dik@cwi.nl
aej@manyjars.WPI.EDU (Allan E Johannesen) (06/03/91)
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.bernhold@red8 (David E. Bernholdt) (06/03/91)
In article <3627@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes: >Of course, this does not help if you get code you will run; but than the >problem remains with other library (non-instrinsic) routines (eg, BLAS SAXPY >etc.). Some change of source is required anyhow. If you have access to (and are willing to use) a macro preprocessor of some sort, it can be quite helpful in simplifying precision changes for routines such as the BLAS, LAPACK, etc. with precision-dependent routine names. For example, I use C-preprocessor on unix systems. I have include files blas.h, linpack.h, etc. which are included at the beginning of any Fortran routine which uses a given library. The include files contain a macro definition for each double or double complex routine in the library mapping it onto the real/complex counterpart. The macro definitions are made only if an appropriate symbol is defined, so the macro definitions are used or not based on a single symbol definition. Then you code everything in one precision, and if you need the other, you run the preprocessor over it with the appropriate symbol definition. If you want to limit yourself to using only "include" preprocessing, you can get the same effect at the expense of a little extra discipline in coding. Instead of something like Call DAXPY(N, A, X, IX, Y, IY) you write include 'daxpy' $ (N, A, X, IX, Y, IY) with the include file containing the "Call DAXPY". Then to change precision, you substitute a set of files with the other precision routines. It's just an automated way of handling the source code changes, really, but I've found it quite useful. P.S. If anyone wants my CPP definitions for BLAS and LINPACK, I can save you the trouble of typing them all in. -- David Bernholdt bernhold@qtp.ufl.edu Quantum Theory Project bernhold@ufpine.bitnet University of Florida Gainesville, FL 32611 904/392 6365
sjc@borland.com (Steve Correll) (06/04/91)
In article <1694@usage.csd.unsw.oz.au> michaelg@hydra.maths.unsw.oz.au (Michael Gerberg) writes: >We have discovered that the -r8 option (single to double precision conversion) >of the f77 compiler (Version 2.0) on our DEC Stations 5000 running ULTRIX >(Version 4.1) is unusable. The trouble is that certain specific intrinsic >functions are not converted to appropriate equivalents.... >...Unfortunately, DEC people here in Sydney >spent a long time trying to persuade us that the bug does not exist... I believe that -r8 is meant to facilitate porting of programs from supercomputer-class machines where the default size of integers, reals, and logicals is 60-64 bits rather than the 32 bits which is common on workstations. To emulate those machines faithfully, the compiler must also change the meaning of the specific intrinsics. I first encountered "-r8" in the Sun Microsystems compilers. The documentation states clearly that it changes the meaning of specific intrinsics, and experiment shows that the documentation is correct. Perhaps you can get the attention of the DEC people by telling them that you've discovered that Sun SPARCstations would work better than DECstations in your applications. :-)
peterson@fman.enet.dec.com (Bob Peterson) (06/04/91)
The Jones are tough to keep up with when the documentation for -r8 is so sparse. These complaints are noted. For V3.0 we followed the precedent set by V2, knowing the holes w/r/t the specifically single-precision intrinsics. Thanks for raising the issue. Specifically single-precision intrinsics always ought to be replaced by their double precision equivalents when compiling with -r8. Note also that -r8 affects REAL declarations but not REAL*4 declarations (presumably your code depends on the size allocated if you're using the non-standard declaration form). \bob DEC Fortran (V3.0 f77)
oles@kelvin.uio.no (Ole Swang) (06/05/91)
Is there an option for the MIPS f77 compiler that will cause all variables
declared (implicitly or explicitly) as INTEGER to be stored as 8 bytes?
I tried -i8, but no success.
advthanksinance...
--
-----------------------------------------------------------------------
Ole Swang assistant lecturer, Dept. of Chemistry, U. of Oslo
-----------------------------------------------------------------------zdenko@katzo.rice.edu (zdenko tomasic) (06/06/91)
It is very unlikely that -i8 or the equivalent exists for MIPS R2000/R3000 chips as they are 32-bit chips. You may have to wait for R4000 (64-bit) to have such a flag (but there is no guarantee it will be implemented). -- ___________________________________________________________________ Zdenko Tomasic, Rice U., Chem. Dept., P.O. Box 1892, Houston, Tx 77251 INTERNET: zdenko@katzo.rice.edu ___________________________________________________________________