How to force compiler to accept intentional type mismatch between actual & dummy args

[sidwest]

I have a large LEGACY FORTRAN program that I am trying to compile in Visual Studio 2008 and am getting errors with type mismatch between actual and dummy arguments. The type mismatch is intentional and has compiled without error for 20 years+ with Sun Fortran's f77 compiler and executes flawlessly.

To anticipate your initial response, let me say that I DO NOT want to rewrite the code; it is huge. I just want to find what options/switches, etc that will force the compiler to use legacy fortran semantics and compile the code as written without errors.

I have included a greatly simplified sample snipit of code at the end of this message to help illustrate the code that is giving the errors. I know that this is not recommended coding practice and that there are probably new fortran language features that make this approach unnecessary today. Again, I just want to force the compiler to accept the intentional type mismatches. The program works just fine this way.

I have reduced the number of arguments in the snipit belowto 3 for simplicity. The actual program has 65 arguments which in the called subroutine SUBMAN have various different types including REAL*8, REAL*4, and INTEGER*4.

I have tried using the OPTIONS /F77 and the Properties setting to use f66 semantics and neither one will allow the code to compile with no errors.

Here is the snipit:

PARAMETER (ARASIZ=252000000)

CHARACTER*1 A(ARASIZ)

LIMNOD=999999

LOCT= 1

LOCC= LOCT + 8* LIMNOD

LOCQ= LOCC + 8* LIMNOD

CALL SUBMAN(A(LOCT),A(LOCC),A(LOCQ))

.

.

.

SUBROUTINE SUBMAN(T,C,Q)

REAL*8 T(1),C(1),Q(1)

.

.

.

Thanks in advance for your help.

[Lorri_M_Intel · Accepted solution]

By default, the DEBUG configuration in Visual Studio sets a variety of command line switches that are intended to help you find coding errors.

For this one, I'd recommend going to the Property page: Fortran->Diagnostics and setting "Check routine interfaces" to "No".

You may find other options on that page that you'll want to change as well.

- Lorri

[TimP]

It should not be surprising that the compiler offers compile time checking for non-portable legacy extensions which haven't been necessary for the last 3 decades, and could never be counted on to work along with F77 code. You still have the option of setting /nogen-interfaces /Qip- to disable this checking and optimizations which are likely to break, but you lose many chances to uncover other risky practices.

[sidwest]

Thanks you Lorri, that worked beautifully. The entire program now compiles with 0 warnings and 0 errors!!!

It also runs a test data case correctly.

Thanks again more than you can imagine.

- Sid

[nvaneck]

But isn't there a problem with the character arguments? I have a routine that needs to handle character string records aas well as real & integer. Two of them actually;: one to read and write the two kinds of records and one to perform any one of several conversions from character strings containing numbers to real or integer, vicee-versa and everything in between. The latter is needed to process hundrsds of variables and thousands of records of varying mode elements unknown until execution. It's the length of character strings passed at the end that do me in, so I've had to find creative solutions to get around the involving wasteful extra steps and duplicate routines.

If there were a way to allow a dummy character string argument to accept an actual binary argumentwithout theroutiine getting fatally mixed up by the hidden arguments fora particular routineit would be nice.

For the conversion routine I solvedthe major part of the problemby making long buffers of each type and equivalencing them in a module. For the read/write routine, I had to write duplicate code.

Are there any better ways?

[Steven_L_Intel1]

In Intel Fortran the character lengths are all passed at the end. If the receiving routine is not looking for them, then they are ignored and harmless. This would not be the case if CVF conventions were in use, where the character lengths follow the address and STDCALL is used.

[nvaneck]

That explains for me; I first wrote these routines unde CVF and ran into a lot of trouble with STDCALL options.

Thank you, Steve.