1

Apologies in advance for what seems to be a very basic question. I'm not a Fortran programmer, unfortunately, but I'm in a position of having to maintain some legacy FORTRAN77 code, and it is not compiling in Intel Visual Fortran Parallel XE 2013 (with VS2010).

The error I'm getting is

error #6633: The type of the actual argument differs from the type of the dummy argument.

It occurs in several calls to subroutines that are defined within the project. This code has the statement 

IMPLICIT REAL(8) (A-H,O-Z)

throughout, in both the calling function and the called subroutine. (It had been REAL*8, but I changed it.)

Doesn't that mean that the arguments, all of which have names that fall into the range (A-H,O-Z), will be two-byte reals? I don't know where they are being declared or otherwise converted to any other type. The only functions called within the subroutines are intrinsic math functions, such as cos, sin, atan2.

Here is an example:

INCLUDE 'common.f'
... ! (many lines of code)

C    Transform from RS to RL
    call RS$RL(0,iobl,1,vrel,xlatgc,gam,az,vph,vth,vr,
 *                 xlatgd,gaml,azl,vphl,vthl,vrl)

which calls

      SUBROUTINE RS$RL(ID,IOBL,IV,VREL,TH,GAM,AZ,VPH,VTH,VR,
 *                 THL,GAML,AZL,VPHL,VTHL,VRL)
C*  DECLARATIONS
      IMPLICIT REAL(8) (A-H,O-Z)
C     IMPLICIT REAL*8(A-H,O-Z)
      DEL = THL-TH
      IF(ID.EQ.0) THEN
C*  TRANSFORM FROM RS TO RL FRAME
        IF(IV.EQ.0) THEN
             VPH  = VREL*COS(GAM)*SIN(AZ)
             VTH  = VREL*COS(GAM)*COS(AZ)
             VR   = VREL*SIN(GAM)
        ENDIF
        IF(IOBL.EQ.0) THEN
             VPHL = VPH
             VTHL = VTH
             VRL  = VR
        ELSE
             VPHL = VPH
             VTHL = VTH*COS(DEL)-VR*SIN(DEL)
             VRL  = VTH*SIN(DEL)+VR*COS(DEL)
        ENDIF
        GAML = ATAN2(VRL,SQRT(VPHL**2+VTHL**2))
        AZL  = ATAN2(VPHL,VTHL)
      ELSE
C*  TRANSFORM FROM RL FRAME TO RS FRAME
        IF(IV.EQ.0) THEN
             VPHL = VREL*COS(GAML)*SIN(AZL)
             VTHL = VREL*COS(GAML)*COS(AZL)
             VRL  = VREL*SIN(GAML)
        ENDIF
        IF(IOBL.EQ.0) THEN
           VPH  = VPHL
           VTH  = VTHL
           VR   = VRL
        ELSE
           VPH  = VPHL
           VTH  = VTHL*COS(DEL)+VRL*SIN(DEL)
           VR   =-VTHL*SIN(DEL)+VRL*COS(DEL)
        ENDIF
        GAM  = ATAN2(VR,SQRT(VPH**2+VTH**2))
        AZ   = ATAN2(VPH,VTH)
      ENDIF
      RETURN
      END

The file common.f contains the line IMPLICIT REAL(8) (A-H,O-Z) at the very top of the file, which is followed by many explicit declarations, none of which include the offending parameters that produce the compile error.

The error messages complain about the arguments, vrel, xlatgc, gam, az.

Bruce E.
  • 23
  • 1
  • 6
  • 1
    Show the declarations and/or specification part (the implicit statement) of the scope that has the CALL statement. You would get this error if the calling scope lacks an appropriate IMPLICIT statement (or explicit declarations) to set the type of the actual arguments to REAL(8). In the absence of an IMPLICIT statement variables starting A-H and O-Z are default real, which is not normally REAL(8) (command line options can change this). The difference between REAL(8) and REAL*8 is a distraction - they are synonyms for that compiler. – IanH Mar 20 '14 at 01:40
  • I agree with IanH, but I would also recommend not to use `$` in your identifiers, it is highly non-standard. Also, I would just use `real*8` everywhere, I see no point in introducing `real(8)' in your case. – Vladimir F Героям слава Mar 20 '14 at 09:18
  • @VladimirF - Yes, those $ characters are a mess. They appear all throughout this library of code, however, so I just haven't gone through the tedium of making the global changes. I will do so for any code that I'll be keeping. Right now I just want to be able to compile this mess to see exactly what it's doing. – Bruce E. Mar 20 '14 at 14:36
  • @IanH - I've edited the OP to reflect that the calling function had an `INCLUDE` statement, and the included file had the `IMPLICIT` statement in it. I had thought that maybe I needed the `IMPLICIT` statement explicitly in the calling function as well, but when I tried that I got an error saying that the order of the statements was incorrect. I have no `USE` statements, so I'm not sure why that was. – Bruce E. Mar 20 '14 at 14:48

1 Answers1

0

real(8) is not the same as real*8. The first is non-portable and could mean different things on different compilers. The second is non-standard but can be relied upon to mean 8-byte reals. Do you get the error message if you switch back to real*8? The error message is because the declaration of the variables in the call disagrees with the declarations in the subroutine. You show the call but not the declaration of those variables. That is what needs to be compared.

Here is a discussion of ways to declare integers: Fortran: integer*4 vs integer(4) vs integer(kind=4). Its very similar for reals ... I'm sure that also already somewhere on stackoveflow.

Community
  • 1
  • 1
M. S. B.
  • 28,968
  • 2
  • 46
  • 73
  • I made the change from `real*8` to `real(8)` only as an experiment to see if it would help with my compile errors. I've kept it since it seemed to be preferred based on some posts I'd read. – Bruce E. Mar 20 '14 at 14:39
  • `real(8)` is wrong. With will some compilers it will give you 8-byte reals; with others it be rejected and your program won't compile. – M. S. B. Mar 20 '14 at 14:48
  • I thought `real*8` was considered to be old-style and that now `real(8)` or `real(kind=8)` was preferred. If not `real(8)`, then what is the preferred syntax? The Intel Fortran compiler seems okay with `real(8)`, BTW. – Bruce E. Mar 20 '14 at 15:04
  • 1
    `real(N)` or `real(kind=N)` are preferred, but the values N are not portable across compilers. The Fortran 90 best practice is to use the `selected_real_kind` intrinsic to determine N. Alternatively, now you can use `use ISO_FORTRAN_ENV` and `real (real64)`. – M. S. B. Mar 20 '14 at 15:21
  • 1
    REAL(8) is not "wrong", it is just not portable - there is a world of a difference. "$" signs in symbols aren't portable either (and are also not standard conforming), so the code isn't hopping across to another processor any time soon. – IanH Mar 20 '14 at 19:48