Incompatability between actual and dummy argument

[Robert_van_Amerongen]

A problem occures with this repect in one of my larger programs, I have isolated it as you can see below.
There is an allocatable array of derived types. And there is a function that has just one element of the array as an argument. If the command line looks like:
ifort /free /extfor:f03 /warn:all opf.f03
the compiler issus error #6633:Actual argument and dummy argument differs.
If I remove the /warn part of the commandline, everything compiles fine and the results are as they ought to be.
What is going on here?

PROGRAM pro

IMPLICIT none

! type definition

TYPE mytype

INTEGER i,j

END TYPE mytype

TYPE(mytype),ALLOCATABLE :: protype(:) ! protype is an array

!

INTEGER :: k

INTEGER :: result

INTEGER :: functie_protype

! allocate and initialise

ALLOCATE(protype(1:3))

DO k=1,3

protype(k)%i = 8*k

protype(k)%j = 10*k

END DO

!

DO k=1,3

result = functie_protype(protype(k)) ! call with just one element of protype array

END DO

STOP

END

!

INTEGER FUNCTION functie_protype(protype) ! protype is a derived type scalar

IMPLICIT none

! type definition

TYPE mytype

INTEGER i,j

END TYPE mytype

!

TYPE(mytype),INTENT(in) :: protype

!

write(*,*) protype

functie_protype = 23456

RETURN

END

[mecej4]

You have two places where you define TYPE(mytype).

As you can see in Metcalf, Reid and Cohen, Fortran 95/2003 Explained, OUP, 2006, p. 148,

"..even if two derived-type definitions are identical in every respect except their names, entities of those two types are not equivalent...Even if the names, too, are identical, the types are different..."

A similar situation existed in Pascal years ago.

One justification of this somewhat surprising feature is that if the language did not impose such a restriction, a compiler would have to ensure that repeated definitions are actually identical. Doing so, especially across separately compiled program units, would be quite difficult.

[Robert_van_Amerongen]

You shed some interesting light on this issue. This program was from my "older" days and I know is not the recommended way of programming. I still thought, however, that it is legal Fortran.That the standaard sets a restriction was unknown to me.

With this in mind one asks what is the situation if we do not use /warn:all. Accept the compiler a basically wrong construct? (By the way, my earlier compiler never complained on this issue.)

It should be near to ideal if a compiler can tell that a type is defined multiple times. In this case these two definitions occurs in two programming units, but still in one file. The message about incompatible types of dummy and actual argument is somewhat misleading because it suggestsyou to look for differences like f.i. a 32 bit real as an actual argument and a 32 bit integer as the dummy agrgument. But I do not know whether a compiler can do that, especially if the definitions are in separate files that are compiled separately, as you mentioned.

Robert

[mecej4]

Intel's /warn:xxx feature is fairly new and quite ambitious. As such, some parts of it are open to improvement. I would think of it as a useful guide, and no more. It can help one find bugs, but it can also give false diagnoses.

Given its fallibility, I should prefer that when /warn is requested it should never generate syntax errors where none would be generated without /warn requested, as in your example. In general, one should be able to turn warnings off, and warnings should not be promoted to errors unless so requested by the user.

If you do not use /warn, and your multiple declarations of a type are all identical, as in your example, the resulting program may run correctly.

You may find g95's error message for your example quite pregnant

Warning (155): Inconsistent types (TYPE(mytype)/TYPE(mytype)) in actual argument lists at (1) and (2)

as it suggests that TYPE(mytype) may not be consistent with TYPE(mytype), at least in the compiler's view!

The Fortran Standard has a tradition of not specifying how a "processor", i.e., compiler+linker+OS, should handle non-conforming code (such as your example above). Thus, the standard has nothing to say as to how Intel's "processor" should deal with your non-conforming example code.

As is typical in compiled languages, Fortran does not support dynamic typing, even with "polymorphic types". Some compilers, notably those from NAG and Lahey, support run-time checking of subprogram arguments for type compability, but I doubt that this works for derived types at all or as well as it does for intrinsic types.

[jarvusluntatintel]

Because of legacy code that I am unable/unwilling to fix (similar to the above example), I have turned off Intel's checking. This is frustrating because if I add an argument to a subroutine and miss adding it to one of the calls to that subroutine, I don't discover it until I get weird runtime behavoir.

Would it be that hard to add an option for asimple byte check like CVF had. So mysubroutine@32 has to be called by 32 bytes worth of arguments? That would catch 95% of the mistakes I make. (I will sometimes build it on an old linux compiler justbecause it will check for this.)

[mecej4]

The @nn decoration was a powerful feature for Fortran-77 code -- a subroutine had a fixed number of arguments. Much of the time, the arguments were all passed on the stack.

In Fortran-90 and beyond, we have OPTIONAL arguments, and INTENT(IN), INTENT(OUT), etc. We have many more types in the language and matching byte counts is not enough. For example, "call subA(i,x)" and "call subA(x,i)", with x an 8-byte DOUBLE and i a 4-byte integer, will match as to byte count, but one of them is wrong. With OPTIONAL arguments, a proper call with some of the OPTIONALs left out will not match the byte count.

The AMD64/Intel64 ABI now has the first few arguments passed through registers, the rest through the stack. There are many more types of possible mismatches between formal and actual arguments. Today's user would probably expect /check_interfaces to do more than byte-count checking. That is why the language added INTERFACE (explicit and implicit) and, in some cases, these interfaces are required.

If maintaining legacy code is important, retaining old tools of the same vintage, as you have done, is probably a wise thing to do.

The Intel compilers excel at producing high performance code from debugged sources. For development and detecting errors, other compilers are better suited.