I don't understand the implicit issue: The type of the actual argument differs from the type of the dummy argument.

[FortCpp]

Dear IVF users and developers,

I want to compile a code using IVF for a simple calculation. The code that I downloaded compiled on Linux using ifort without any problem.

But on windows there are compile problems when I add the files to IVF following the makefile. The code is pure computational. So I think there is no problem to use it on a different platform. It is really inconvenient for me to use a remote linux machine to make the code work and I prefer to work with IVF.

The error messages that I get are #6633 The type of the actual argument differs from the type of the dummy argument.

The source looks like the following:

      SUBROUTINE CFFTB (N,C,WSAVE)
      DIMENSION       C(1)       ,WSAVE(1)
      IF (N .EQ. 1) RETURN
      IW1 = N+N+1
      IW2 = IW1+N+N
      CALL CFFTB1 (N,C,WSAVE,WSAVE(IW1),WSAVE(IW2))
      RETURN
      END

The error points to call cfftb1 line. It could be a implicit issue according to my understanding so far. But I don't understand it very well and I have no idea how to fix it. Please find all the source and the input files in the attachment.

my ifort version is 14.0.1.139. I am using windows 8.1 and MSVS professional 2012.

Thanks.

[mecej4]

The *.f files in the lib subdirectory contain old-style declarations of array dummy arguments, showing a dimension of (1). If, in your project settings, you have enabled some settings that check calling sequences, the compiler will flag an error. 

You have two choices: (i) disable checking across subprograms, (ii) rewrite the call statement as

CALL CFFTB1 (N,C,WSAVE,WSAVE(IW1:),WSAVE(IW2:))

You may find it useful to change declarations of 1-D array dummy arguments to show (*) instead of (1), and make similar changes to higher dimensional array arguments.

You can also adapt your makefile to Windows and use it with nmake.

With the fix that I have indicated, your program ran and gave "40  -7.84250584157089" as the last line of output. If you believe that your program ran correctly on Linux, you may compare this result to the corresponding result from a run on Linux. Your program has several instances of referencing variables that have not been initialized, so the result could be unpredictable or incorrect.

[andrew_4619]

You also have 

C
C $Id: cfftb1.f,v 1.3 1998/09/23 15:42:28 noe Exp $
C Part of the fftpack suite of files
C
      SUBROUTINE CFFTB1 (N,C,CH,WA,IFAC)
      DIMENSION       CH(1)      ,C(1)       ,WA(1)      ,IFAC(2)

Because there are no types declared variables starting with the letters IJKLMN default to type integer all else to type real.

You are passing real WSAVE into integer IFAC. I would suggest the call is wrong. On some older compilers you might get away with this as on the address of the start of the array is passed however the compiler is correctly showing a bug in the code.

[IanH]

There's also a type mismatch - the last dummy argument in the CFFTB1 routine is implicitly declared integer. 

[FortCpp]

mecej4 wrote:

The *.f files in the lib subdirectory contain old-style declarations of array dummy arguments, showing a dimension of (1). If, in your project settings, you have enabled some settings that check calling sequences, the compiler will flag an error. 

You have two choices: (i) disable checking across subprograms, (ii) rewrite the call statement as

CALL CFFTB1 (N,C,WSAVE,WSAVE(IW1:),WSAVE(IW2:))

You may find it useful to change declarations of 1-D array dummy arguments to show (*) instead of (1), and make similar changes to higher dimensional array arguments.

You can also adapt your makefile to Windows and use it with nmake.

With the fix that I have indicated, your program ran and gave "40  -7.84250584157089" as the last line of output.

Thanks very much for the response. Could you please tell me more about your fix?

1. I tried the "disable checking across subprogram" choice as you mentioned. (/warn:nointerface). The code did compile, but there is a run time error related to this issue. When I ran the compiled file, it reported the subscript out range (or something like that).

2. I changed CFFTB1, CFFTI1 and CFFTF1 calls according to your suggestion. Basically after the modification I have something like these in cfftb.f cffti.f and cfftf.f:

      CALL CFFTB1 (N,C,WSAVE,WSAVE(IW1:),WSAVE(IW2:))

      CALL CFFTI1 (N,WSAVE(IW1:),WSAVE(IW2:))

      CALL CFFTF1 (N,C,WSAVE,WSAVE(IW1:),WSAVE(IW2:))

But still I got similar problems except I don't have the error on the cfftf1 call this time.

I may did something wrong so could you please tell me more about your fix?

Thanks again.

[FortCpp]

app4619 wrote:

You also have 

C
C $Id: cfftb1.f,v 1.3 1998/09/23 15:42:28 noe Exp $
C Part of the fftpack suite of files
C
      SUBROUTINE CFFTB1 (N,C,CH,WA,IFAC)
      DIMENSION       CH(1)      ,C(1)       ,WA(1)      ,IFAC(2)

Because there are no types declared variables starting with the letters IJKLMN default to type integer all else to type real.

You are passing real WSAVE into integer IFAC. I would suggest the call is wrong. On some older compilers you might get away with this as on the address of the start of the array is passed however the compiler is correctly showing a bug in the code.

Thanks for pointing this out for me. It could be a program error as you mentioned. But on a linux machine with ifort there is no error (I am sure the ifort is released in spring 2014 though I don't have its version right now). I totally agree with you for the type error in the calling and in fact there is no information about the complex type announcement since there are lines which pass complex arrays. I am just guessing whether there are other rules or the compiler is smart enough for handling the calling issues. I am not sure whether such calling issues are bugs since the linux version ifort gives no errors. What do you think?

I just want the code to run with minimum or no modification. I think I'd not change too many things.I just want to understand the algorithms in the code and I never program in this way.

[mecej4]

Many older codes (F77 or even earlier) will give you lots of subscript and argument mismatch errors if you attempt to run modern checks on them. Unless you are familiar with the purpose and workings of the old code, it is probably not worth your time to fix it so that it will stand up to subscript and argument checks. Therefore, the simplest solution at this point is for you to remove subscript checking options from your project settings, assuming that you have enough confidence in the newer parts of the code, if any, that they do not need subscript checking.

Similar comments apply w.r.t. to compiler options if you are going to use the makefile instead of the IDE. Incidentally, I gather from your makefile that on Linux the option used was just -O2, which implies that no runtime checks were made for argument matching, subscript range, etc.

[FortCpp]

Thanks for all comments.

I made the code work by setting check bounds to no. I think that's what mecej4 mentioned. I am not going to figure out how the details of fixing the subroutines for now.

[mecej4]

FortCpp, there is one point to which I want to draw your attention before this thread fades into obscurity.

In pw_dft.f90, you have the statement

if(BAND_STRUCTURE.eq..true.) then 

Although Intel Fortran will digest this statement, the usage of the .eq. operator to compare logical expressions is not standard-conforming. For comparing logical expressions, please use the .EQV. and .NEQV. operators. In your code, it suffices to change the line to

if(BAND_STRUCTURE) then

[FortCpp]

mecej4 wrote:

FortCpp, there is one point to which I want to draw your attention before this thread fades into obscurity.

In pw_dft.f90, you have the statement

if(BAND_STRUCTURE.eq..true.) then 

Although Intel Fortran will digest this statement, the usage of the .eq. operator to compare logical expressions is not standard-conforming. For comparing logical expressions, please use the .EQV. and .NEQV. operators. In your code, it suffices to change the line to

if(BAND_STRUCTURE) then

mecej4,

Thanks for your advice. I'll avoid of using operators to compare logical expressions in my code.