Internal compiler error: internal abort

[anishtain4]

I get this error while I'm trying to compile the file Convective.f90. files are attached here: http://ifile.it/e7qdr2b
error is for the assigning line of this subroutine:

[bash]SUBROUTINE SCHEME(KM,PrR,PrL,DX,DY,L,F)
  INTEGER,INTENT(IN)::KM
  REAL,INTENT(IN)   ::PrR(5),PrL(5),DX,DY,L
  REAL,INTENT(OUT)  ::F(KM)
!  F = AVE(KM,PrR,PrL,DX,DY,L)
END SUBROUTINE[/bash]

Which has been commented out in the above code.
What should I do? I tried to make it a function instead of subroutine but the assignment makes this error

[Steven_L_Intel1]

Which exact compiler version are you using? Which options did you use when compiling?

Your ZIP is missing the source to module TYPES, perhaps others.

[anishtain4]

I'm using Intel Visual Fortran Compiler Professional Edition 11.1 integrated with VS2008

Here is the complete code: http://ifile.it/z3l2hf9

all the options are defaults except I have added /heap-arrays:10000

I already solved it with changing all the FUNCTIONs to SUBROUTINEs but I just reported this in case it could help for later versions

[Steven_L_Intel1]

When I compile with version 12, it gives me errors each time you reference function F because F returns an array and you do not have the required explicit interface for function F. It could be that with the older version you have, this mismatch triggers the internal compiler error.

Perhaps you could add F to a module and USE the module. Or, as I did for testing, added an explicit interface in each of the procedures that calls F, but I don't recommend this as it is error-prone. When all uses have an explicit interface, the code compiles successfully in version 12.0.4.

I do not recommend using any value for Heap Arrays other than 0. Other values don't give you any benefit.

[anishtain4]

isn't explicit interface only for assumed shape arrays? I rather not to use it because in my believe it's code duplication and when I want to change something most of times I forget changing it's interface too.

[Steven_L_Intel1]

There are many things that require an explicit interface. In your case, F is a function that returns an array - that requires an explicit interface. See Doctor Fortran Gets Explicit (that reminds me I need to update this article for F2008).

I agree that you don't want code duplication. That's why I recommend putting your functions and subroutines in a module. However, there's a problem you can create by doing so if you're not careful - see the section "Up Periscope" of Doctor Fortran in "Too Much of a Good Thing?"

[mecej4]

>isn't explicit interface [required] only for assumed shape arrays?

Yes, in one context. The context you have is different. The result type of a function with an implicit interface is a scalar of a type determined by the IMPLICIT rules in effect (default: I-N integer, A-H and O-Z real).

>I rather not to use it because in my belief it's code duplication and when I want to change something most of times I forget changing its interface too.

It is precisely to save you from your own forgetfulness (or folly) that there are rules regarding explicit interfaces. Those rules are a safety/consistency feature, which you are advised to keep enabled until you can trust yourself to make consistent changes.

[Steven_L_Intel1]

Well, no, the rules for explicit interfaces aren't "for your protection". They are there for the situations where the compiler must know what the called procedure expects when calling a procedure with the particular attributes. In the case of a function returning an array, the calling procedure must allocate space for the function result and pass a "hidden argument" with the address of that space. For an assumed-shape array, the caller must pass a descriptor rather than a simple address. For a procedure with OPTIONAL arguments, the caller needs to know that the arguments are optional so it can pass the appropriate indicator.

I am strongly in favor of using modules or contained procedures where appropriate, so that every procedure in your application has an explicit interface made visible to the caller. This will help you avoid errors that are so easy to run into when using the F77-style "external procedures". Ideally, you should never write an INTERFACE block for a Fortran procedure in your application as they can get out of synch with the actual procedure.