Compiler interface checking with derived-type arguments

[dboggs]

My program calls an external subroutine with a single argument of type derived. There is no explicit interface. The declaration of the actual argument in the program is identical to the declaration of the dummy argument in the subroutine. Nevertheless, the compiler gives an error "The type of the actual argument does not match the type of the dummy argument" when /warn:interfaces is in effect (as it is by default). Why? Is this expected? It does not happen when the argument is a simple variable.

I can get around this by providing an explicit interface, or putting the subroutine in a module, but there may be reasons to prefer the more primitive traditional form. I would like to better understand why the compiler behavior is different when the argument is of a derived type. Is it documented?

[dboggs]

Sorry, I was hasty. I found the answer by searching this forum--in a response my own previous submission a few years ago!

The problem is that the components of a derived type do not necessarily have the same order, and the compiler must recognize this when it checks the implicit interface. The problem can be solved by including the SEQUENCE statement in the derived type definitions.

I still think that the documentation in IVF help could be improved on this matter. If it's there, someone please direct me to it!

[IanH]

The description of the derived type definition statement (TYPE my_type...END TYPE) for version 15.0 (https://software.intel.com/en-us/node/526880) explains that different definitions from different scoping units (that don't have SEQUENCE or BIND(C) plus other conditions) result in different types.  This is the underlying cause of the observed problem.