topic Add IMPLICIT NONE to your in Intel® Fortran Compiler

eliminating g77 intrinsic function

jayb — Mon, 22 Dec 2014 16:06:08 GMT

In the applications that I have ported from g77 to Intel Fortran, many of the remaining run-time bugs are due to use of g77 intrinsic functions. I am trying to come up with a way to track them down before they cause run-time errors. I have an idea based on the following small example, but wanted to elicit ideas from this community.

Here is a g77 function that kills a process, given the process id:

INTEGER FUNCTION KILLER(PID)
INTEGER*4 PID, RESULT
CALL KILL(PID,9,RESULT)
KILLER=RESULT
END
Notice the signature of the kill subroutine. This snippet of code would be correctly implemented as follows in Intel Fortran:

INTEGER FUNCTION KILLER(PID)
USE IFPORT
INTEGER*4 PID, RESULT
RESULT = KILL(PID,9)
KILLER=RESULT
END
As in C, kill() is an integer function with 2 arguments.

This was an easy coding change to make, but the run-time bug that it caused was not as easy to track down. I would rather find these at compile time. I noticed that if I add "USE IFPORT" to the original implementation with the g77 intrinsic, I get a compile error. Code is:

INTEGER FUNCTION KILLER(PID)
USE IFPORT
INTEGER*4 PID, RESULT
CALL KILL(PID,9,RESULT)
KILLER=RESULT
END
and compile error is:

killererr.for(4): error #6552: The CALL statement is invoking a function subprogram as a subroutine. [KILL]
CALL KILL(PID,9,RESULT)
------------^
killererr.for(4): error #6784: The number of actual arguments cannot be greater than the number of dummy arguments. [KILL]
CALL KILL(PID,9,RESULT)
------------^
This is a good thing! So now I'm wondering: Is there a compiler switch or some other way to indicate that I would like to "USE IFPORT" on all of my code? Or any other approach that you can suggest, short of searching for every g77 intrinsic (I found an on-line reference) in the source code?

Thanks,
JayB

Add IMPLICIT NONE to your

mecej4 — Mon, 22 Dec 2014 16:58:48 GMT

Add IMPLICIT NONE to your subprograms, and use the /warn:interfaces compiler option. The former would have caused the use of KILL as a function, and the latter would have compared argument usage for consistency with argument declarations.

Hi, Mecej4. I tried your

jayb — Mon, 22 Dec 2014 20:02:54 GMT

Hi, Mecej4. I tried your idea on the example above, adapted to Linux (-warn interface) and did not get any warnings. Event "-warn all" did not give me warnings. Thanks, though.

Since "USE IFPORT" seems to ferret these out, I was hoping to find a way to indicate the use of the portability module without having to insert it into every function and subroutine.

-- JayB

Do all (most) of your

jimdempseyatthecove — Mon, 22 Dec 2014 21:17:18 GMT

Do all (most) of your subroutines and functions have a USE yourOwnModuleHere?

If so, you can insert the USE IFPORT into that module.

If not, then you might consider doing that so you can easily switch back and forth from g77 and ivf.

Jim Dempsey

Jim,

jayb — Mon, 22 Dec 2014 21:47:09 GMT

Jim,

Since this is a legacy application, the source code does not contain any modules. But that sounds like an interesting idea, at least in terms of grouping subprograms for the type of check I have in mind.

Thanks,
JayB

Well, I tried wrapping lots

jayb — Mon, 22 Dec 2014 22:27:58 GMT

Well, I tried wrapping lots of this application's small machine-generated (from RATFOR) FORTAN 77 files into a module. A few problems ensued:

1) Since modules are part of modern Fortran, the module construct would not be processed in a file with the .for extension. So I tried .f90

2) In a .f90 file, most of the FORTRAN 77 syntax was permissible. But continuation lines (column 6 containing *) and comment lines (column 1 containing C) generated so many errors that the compiler decided to end things after a few hundred lines.

Looking back, I'm pretty impressed that I got as far as I did!

The original author has since provided me with an almost-complete list of g77 intrinsic functions that he used. So I might just go ahead and use that; it's a very small subset of all g77 intrinsic functions.

JayB

Quote:Jayb wrote:Since

mecej4 — Mon, 22 Dec 2014 22:53:49 GMT

Jayb wrote:
Since modules are part of modern Fortran, the module construct would not be processed in a file with the .for extension. So I tried .f90.

This is a misconception. A file suffix of .for or .f merely signifies to the compiler that the source file is in fixed format. With a suffix of .f90, the file is expected to be in free format, where the syntax for continuation lines is different.

You're right. I never

jayb — Mon, 22 Dec 2014 23:19:36 GMT

You're right. I never thought to add a MODULE definition using fixed-format. That's definitely an improvement for my current one-time purposes. Although I'm getting some other odd compilation errors, I have already detected one more use of a g77 intrinsic used differently than an Intel Fortran portability function. Thanks.