SLATEC
in [Fortran]
|
Prev: pointer and allocatable array problem
Next: BLAS: dgemm
From: Beliavsky on 5 Feb 2007 11:32 John Burkardt has many Fortran 90 codes at his site, many of which are translations of Fortran 77 code. SLATEC is a big Fortran 77 library with a Fortran 90 translation (free source form) at http://www.csit.fsu.edu/~burkardt/f_src/slatec/slatec.html . Having replaced non-integer do loop variables in the original SLATEC with integers, the F90 version now compiles with g95, and when it is run, it passes all tests. It also compiles and runs with Gfortran and Intel Fortran. For Gfortran it passes TEST01 but then stops with the message * RESULT OVERFLOWS BECAUSE N AND/OR M TOO BIG With Intel Fortran the program stops early with the message ************* WARNING -- 1 TEST(S) FAILED IN PROGRAM TEST04 ************* TEST05 passed all tests. * NUMBER OF TERMS > 1000 What puzzles me is that g95 emits MANY warnings about inconsistent variable types, for example In file slatec_prb.f90:13254 call STEST(2*LENY,CY,CT10Y(1,KN,KI),SSIZE2(1,1),1.,KPRINT) 1 In file slatec_prb.f90:55952 subroutine STEST (LEN, SCOMP, STRUE, SSIZE, SFAC, KPRINT) 2 Warning (155): Inconsistent types (COMPLEX(4)/REAL(4)) in actual argument lists at (1) and (2) In the code where STEST is called, CY is declared COMPLEX CY(7) but the beginning of subroutine STEST is subroutine STEST (LEN, SCOMP, STRUE, SSIZE, SFAC, KPRINT) REAL SCOMP(*), STRUE(*), SSIZE(*), SFAC, SD, RELEPS, R1MACH so SCOMP is declared REAL Such warnings are also produced when compiling the original SLATEC. The original SLATEC has been downloaded about 1.6 million times from Netlib, and the compiled program does run to completion with g95, so I am reluctant to believe that it has lots of bugs. Is there some convention or language rule I am unaware of that causes the code to work?
From: mecej4 on 5 Feb 2007 13:29 Beliavsky wrote: > John Burkardt has many Fortran 90 codes at his site, many of which are > translations of Fortran 77 code. SLATEC is a big Fortran 77 library > with a Fortran 90 translation (free source form) at > http://www.csit.fsu.edu/~burkardt/f_src/slatec/slatec.html . Having > replaced non-integer do loop variables in the original SLATEC with > integers, the F90 version now compiles with g95, and when it is run, > it passes all tests. It also compiles and runs with Gfortran and Intel > Fortran. For Gfortran it passes TEST01 but then stops with the message > > * RESULT OVERFLOWS BECAUSE N AND/OR M TOO BIG > > With Intel Fortran the program stops early with the message > > ************* WARNING -- 1 TEST(S) FAILED IN PROGRAM TEST04 > ************* > TEST05 passed all tests. > * NUMBER OF TERMS > 1000 > > What puzzles me is that g95 emits MANY warnings about inconsistent > variable types, for example > > In file slatec_prb.f90:13254 > > call STEST(2*LENY,CY,CT10Y(1,KN,KI),SSIZE2(1,1),1.,KPRINT) > 1 > In file slatec_prb.f90:55952 > > subroutine STEST (LEN, SCOMP, STRUE, SSIZE, SFAC, KPRINT) > 2 > Warning (155): Inconsistent types (COMPLEX(4)/REAL(4)) in actual > argument lists at (1) and (2) > > > In the code where STEST is called, CY is declared COMPLEX CY(7) > > but the beginning of subroutine STEST is > > subroutine STEST (LEN, SCOMP, STRUE, SSIZE, SFAC, KPRINT) > REAL SCOMP(*), STRUE(*), SSIZE(*), SFAC, SD, RELEPS, R1MACH > > so SCOMP is declared REAL > > Such warnings are also produced when compiling the original SLATEC. > The original SLATEC has been downloaded about 1.6 million times from > Netlib, and the compiled program does run to completion with g95, so I > am reluctant to believe that it has lots of bugs. Is there some > convention or language rule I am unaware of that causes the code to > work? > I think that these warnings are caused by the old Fortran way of doing memory management, compounded with the requirement that arguments in subroutines could not be EQUIVALENCE-d to locals. If you look at typical FEM programs, such as DLEARN, they allocate a huge array in blank common declared in the main program, and dole out parcels of that array as arguments to subroutines. It is to be expected that argument types will not match in these circumstances. -- mecej4
From: Tim Prince on 5 Feb 2007 21:27 Beliavsky wrote: > What puzzles me is that g95 emits MANY warnings about inconsistent > variable types, for example > > In file slatec_prb.f90:13254 > > call STEST(2*LENY,CY,CT10Y(1,KN,KI),SSIZE2(1,1),1.,KPRINT) > 1 > In file slatec_prb.f90:55952 > > subroutine STEST (LEN, SCOMP, STRUE, SSIZE, SFAC, KPRINT) > 2 > Warning (155): Inconsistent types (COMPLEX(4)/REAL(4)) in actual > argument lists at (1) and (2) > > > In the code where STEST is called, CY is declared COMPLEX CY(7) > > but the beginning of subroutine STEST is > > subroutine STEST (LEN, SCOMP, STRUE, SSIZE, SFAC, KPRINT) > REAL SCOMP(*), STRUE(*), SSIZE(*), SFAC, SD, RELEPS, R1MACH > > so SCOMP is declared REAL > > Such warnings are also produced when compiling the original SLATEC. > The original SLATEC has been downloaded about 1.6 million times from > Netlib, and the compiled program does run to completion with g95, so I > am reluctant to believe that it has lots of bugs. Is there some > convention or language rule I am unaware of that causes the code to > work? > In the Fortran 77 standard (p. 15-16), it says the type of the actual argument must agree with the associated dummy argument. However, there isn't a uniform method for checking on this, within f77 syntax. Typical implementations are such that the code will work, if no syntax error is raised. There might be alignment restrictions on whether it works. This could have been true way back to the f66 compiler I learned on. If you are asking current ifort to diagnose such potential problems, you will need -gen-interfaces -warn:interfaces (Windows version; linux would be slightly different). Earlier versions of ifort didn't have this facility.
From: glen herrmannsfeldt on 5 Feb 2007 23:26 mecej4 wrote: (snip) >> call STEST(2*LENY,CY,CT10Y(1,KN,KI),SSIZE2(1,1),1.,KPRINT) >> 1 >> In file slatec_prb.f90:55952 >> >> subroutine STEST (LEN, SCOMP, STRUE, SSIZE, SFAC, KPRINT) >> 2 >> Warning (155): Inconsistent types (COMPLEX(4)/REAL(4)) in actual >> argument lists at (1) and (2) As far as I know, it is technically illegal in the versions of the standard that I have. I believe also that COMPLEX variables are required to have the real part adjacent to the imaginary part, and in that order. With all the other requirements that the standard supplies, unless it is specifically checked, it is very likely to work. It might be less common than dimensioning arrays (1), but common enough in older code that a warning instead of error seems reasonable. -- glen
|
Pages: 1 Prev: pointer and allocatable array problem Next: BLAS: dgemm |