Argument checking in Fortran?

[gert_massa]

Is it possible to tell the compiler to check the number of argument of subroutines at compile or link time? It is really annoying to have crashes at run-time when you add an argument to some subroutine but forget to change the call statements at some locations. We used to have same errors at link time on windows 32bit because of the use of the Compaq compatibility flag. Unfortunately we had to remove this flag because of same issues with MKL libraries. Is it possible to have this check done anyway even on windows 64 bit?

[Steven_L_Intel1]

Yes, and this is the default when you create a new project. If you migrated a project from CVF it would not be set. In the project properties, set Diagnostics > Check Routine Interfaces. This will check far more than argument count and will alert you to mismatched types and more.

[gert_massa]

I'm using make files to build my project. Which copiler/linker flags do I need to add?

[Jugoslav_Dujic]

Add /warn:interfaces to the compiler's command line. In versions prior to 11.1, you also need /gen-interfaces (now, the former automatically switches on the latter).

[gert_massa]

Great! But when I do this I get a lot of error on not maching types when I use LADDR defined as

TYPE PTR
INTEGER*4, POINTER :: space(:)
INTEGER*4, POINTER :: p
INTEGER(ADDR_KIND) :: w
END TYPE PTR

INTEGER(ADDR_KIND) :: MSPAC
INTEGER(ADDR_KIND) :: NSPAC
INTEGER*4, PARAMETER :: MxARRAY = 5999
INTEGER*4, PARAMETER :: LxDYNAM = 5001
INTEGER*4, PARAMETER :: MxTEMPO = 50

TYPE(PTR), DIMENSION(0:MxARRAY) :: LADDR
TYPE(PTR), DIMENSION(0:MxTEMPO) :: LADDT

on lines were I use the %p

error #8299: A scalar actual argument must be passed to a scalar dummy argument unless the actual argument is of type character or is an element of an array that is neither assumed shape nor pointer. [LNBEM]
CALL MKBCPTR (LADDR(LxLNBEM)%p,NNBEM
-----------^

were MKBCPTR is defined as

SUBROUTINE MKBCPTR (LNBEM,NNBEM,BCPTR
+ ,NPOIN,NOVPT,LUTEW,IDEBG)
C
IMPLICIT NONE
C
C --- Arguments
C
INTEGER*4 LNBEM(*)
INTEGER*4 NNBEM
INTEGER*4 BCPTR(*)
INTEGER*4 NPOIN
INTEGER*4 NOVPT
INTEGER*4 LUTEW
INTEGER*4 IDEBG

Anything I can do to get rid of these huge amount of errors?

[Steven_L_Intel1]

See I've Come Here For An Argument - the section on Sequence Associaton. You're passing a scalar p to an array LNBEM, which the language doesn't allow. Even if p was an array, it would be disallowed because it's a pointer. Your code is not legal Fortran and the compiler now caught you at it. (This is from the "Be Careful Of What You Wish For" department...)

What is the intention here? Does MKBCPTR know that only one element is being passed? What is in p?

[gert_massa]

No, MKBCPTR is using all the elements in the array of LNBEM. This way of coding dates back from the moment we started using fortran 95 and reworked our code to use dynamic allocation but we still use a kind of memory manager which associates each allocated array to some integer id. LADDR(number)%p is then used to transform then integer number to a pointer and the subroutine call will make sure to cast it to the correct type. How can I get this code working without errors? Or can I disable these kind of errors?

[Steven_L_Intel1]

Try adding:

!DEC$ ATTRIBUTES NO_ARG_CHECK :: LNBEM

after its declaration in MKBCPTR. That may do it. You may need a similar fix anywhere you break the rules this way.

[gert_massa]

You really don't want to know how many times we break the rules in our code :(((
Can I not filter all the error this type?

[Steven_L_Intel1]

Turn off argument checking. You get all of it or none of it. Since you break the rules, you can't use the compiler's diagnostics for following the rules.

[Jugoslav_Dujic]

Quoting gert.massa

We used to have same errors at link time on windows 32bit because of the use of the Compaq compatibility flag. Unfortunately we had to remove this flag because of same issues with MKL libraries.

Since we're back to square one: I don't know which issues with MKL you had. At least in theory, MKL should work with CVF calling convention, as long as you link with mkl_intel_s.lib. See the first note at the end of MKL Advisor page.

[gert_massa]

Indeed, in theory it should but for the blacs ans scalapack libs some on the sysbols are missing. I reportred this issue to intel support but they decided not to fix it.