argument mismatches - any hope?

[robberman]

Hello,

I am having trouble compiling a program with Intel VF that used to compile and run with COMPAQ VF. Ive pasted the offending code below. The compiler is complaining of the mismatch in variable types between Z (real*8) in main program and the variables HA and KA in the subroutine (which are defined as integers, but are aligned with Z).

Im not sure how/why this ran with COMPAQ and whether there is some trick in how one defines variables that can enable this to compile and run with Intel VF.

I've uploaded the program in case you want to look at the actual code.

Any advice would be most appreciated. Thank you very much!

Rob

Main program:

CALL M8SCLJ( 1, 1, N, N, 1, N, 1, 1,

* Z(LASCAL), Z, Z, G )

SUBROUTINE M8SCLJ( MODE, NNCON, NN, NG, N, NB, NE, NKA,

* ASCALE, HA, KA, G )

IMPLICIT REAL*8(A-H,O-Z)

INTEGER*2 HA(NE)

INTEGER KA(NKA)

DOUBLE PRECISION ASCALE(NB), G(NG)

[TimP]

You probably have /gen-interfaces on (it's default in setup for Visual Studio GUI). I still have trouble knowing which of /gen-interfaces and /warn-interfaces implies the other, as it's not clear in the docs. The check only tells you that you've violated Fortran language standard; it tells nothing about what will happen at run time if you turn off the check and proceed (possibly nothing, if the data aren't used in the conflicting subroutine, in which case, there's no reason not to fix it).
Compaq compiler had no way of checking this between different source files, except possibly with full debug. It would probably have warned about such conflicts within a single source file.

[mecej4]

The Intel compiler tries harder than CVF to check for consistency across subprogram boundaries within a source file. You did not have "trouble" compiling the source code -- you were bothered by seeing some warning messages. You can just ignore them (considering the vintage of the code), direct them to the NUL device, or turn them off with the /warn:noalign compiler option.

[Steven_L_Intel1]

The program built with Compaq Fortran because that compiler did not have as extensive a diagnostic capability for argument mismatch checking as Intel Fortran does. Your program is not legal Fortran as the language requires that arguments match in type, kind and rank. However, many programmers used to write deliberate mismatches of this type and sometimes they were harmless. It is not at all clear to me if they are harmless in your program, since you pass double-precision variables that are then used in computation as integers of various lengths. I don't pretend to understand your code. It may be ok, or it may give incorrect results - especially if integers get "fetched" as reals.

If you believe that these mismatches are "safe", you can turn off the error checking on a global basis by setting the project property Fortran > Diagnostics > Check Routine Interfaces to "No". If you want to disable it on these specific arguments only, add:

!DEC$ ATTRIBUTES NO_ARG_CHECK :: A,HA,KA,KB

to subroutine M2APR1.

[GVautier]

Hello

As far as I can understand your program, HA and KA arguments of the function M8SCLJ are only used for input and the function is only used twice in one source file.


I think that a turnaround may be found using pointer.

For example something like that may work

CALL M8SCLJ( 1, 1, N, N, 1, N, 1, 1,

* Z(LASCAL), Z, Z, G )

SUBROUTINE M8SCLJ( MODE, NNCON, NN, NG, N, NB, NE, NKA,

* ASCALE, ha8, ka8, G )

IMPLICIT REAL*8(A-H,O-Z)

DOUBLE PRECISION ASCALE(NB), G(NG), HA8, KA8

INTEGER*2 HA(NE)

pointer (ptr_ha,ha)

INTEGER KA(NKA)

pointer (ptr_ka,ka)

ptr_ha=loc(ha8)

ptr_ka=loc(ka8)

But it is clear that it is only a turnaround.

The better solution, in my opinion, is to try to replace the Z array by a type/structure array.

Unfortunately, legacy program used to abuse of these solutions in a time where structurated datas were inexistent.

[jparsly1]

Ah yes, this is good ole MINOS non-linear optimization code. This goes back to before we had allocatable arrays, so the program allocates one big array and then slices it up using the argument list. You see how this works in the default main routine:

DOUBLE PRECISION Z(150000)
DATA NWCORE/150000/
.
.
CALL MINOS1(Z, NWCORE)
STOP
END

Z is a generic workspace, sliced up into integer and real sections according to the particular problem being solved. So long as "call by reference" applies, this works just fine. A subroutine needs some workspace, and it gets passed an address somewhere inside the big generic workspace.

In this case I'd just turn off the interface checking.

[robberman]

Thanks. Nice to see there's someone out there whose from my generation!

[robberman]

Thanks very much.

[robberman]

Thanks very much.

[robberman]

Thanks very much, Steve.