Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Ankündigungen
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.
29283 Diskussionen

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

sidwest
Einsteiger
3.588Aufrufe

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.

0 Kudos
1 Lösung
Lorri_M_Intel
Mitarbeiter
3.589Aufrufe

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

Lösung in ursprünglichem Beitrag anzeigen

6 Antworten
Lorri_M_Intel
Mitarbeiter
3.590Aufrufe

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
Geehrter Beitragender III
3.589Aufrufe
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
Einsteiger
3.589Aufrufe

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
Neuer Beitragender I
3.588Aufrufe

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
Mitarbeiter
3.589Aufrufe
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
Neuer Beitragender I
3.588Aufrufe

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

Thank you, Steve.

Antworten