error #6618: The INTERFACE/CONTAINS stack is full. This means that modules are being 'used' in a circular way.

[Ahmad_S_]

I am contributing to a large finite element code written in Fortran. I added a very simple subroutine to the code and the compiler complained with

error #6618: The INTERFACE/CONTAINS stack is full. This means that modules are being 'used' in a circular way.

I used Intel compiler 15.0.2. After probing here and there, the problem boiled down to a preprocessing interface. My conclusion is that there seems to be a limit on the number of nested preprocessing interfaces. Here is a simple code that should replicate this error. I compile this code simply like ifort -fpp ut_test.f90

[Martyn_C_Intel]

Hi,

      I was able to reproduce the problem that you report. This is not related to the fpp preprocessor. It is the compiler complaining about the depth of nesting of interface blocks - a depth of 14 in your case. It looks like the compiler's limit is nesting 10 deep. I'm not sure why you are programming in this way, I haven't seen anything like this before. It would be simplest just to collect the interfaces together in a single module, and use that module one from each subroutine. If you are not willing to use Fortran90 modules in this way, perhaps you shouldn't use Fortran 90 interface blocks, either. But another solution might be to group all the interfaces in a single include file, without any nesting, and include that into each subroutine.

Of course, it would better still if some or all of the subroutines could go into modules, then you might not need interface blocks at all. But I guess you have reasons for not wanting that sort of modernization and restructuring.

[jimdempseyatthecove]

Your usage is unusual to say the least. The error emission (I believe) is an attempt to overt an infinite loop that crapps out with stack overflow (though this case should not overflow).

I seem to recall a post on this forum referencing an undocumented option to circumvent these internal limits. If you are lucky, you might find it (or someone here might recall the option).

You should convert the #include format to USE module format. Keep in mind that INTERFACE to self is not permitted.

Jim Dempsey

[mecej4]

The message "modules are being 'used' in a circular way" is perhaps not strictly correct, but you have interfaces nested to a depth of 14. As others have stated, this is unusual and I cannot discern any purpose for such nesting except as a compiler torture test.

In fact, there are no modules here, just nested interfaces. To see this, I replaced the single quotes on the include lines by double quotes and ran the program through Cygwin/GNU cpp -E ut_test.f90 | grep interface | cat -n, which gave me:

     1  interface
     2  interface
     3  interface
     4  interface
     5  interface
     6  interface
     7  interface
     8  interface
     9  interface
    10  interface
    11  interface
    12  interface
    13  interface
    14  interface
    15  end interface
    16  end interface
...

[Martyn_C_Intel]

Jim may be thinking of the option -override-limits   (-qoverride-limits in the latest compilers). This can be used to override certain internal limits during optimization, that are intended to keep memory usage and compile times within reasonable bounds. It's not directly documented, but the optimization report may tell you when an internal limit was exceeded, causing optimization to be reduced, and mention -qoverride-limits as a possible workaround.

However, -qoverride-limits has no effect on language-related limits in the front end, so I do not expect it to make any difference here.

The rewrites suggested above are your best bet.

[Ahmad_S_]

Thanks everyone for their responses. As pointed out by all of you, having these many nested interfaces is unusual and probably unnecessary. In most cases, it not necessary to leave the include statements in the interface.

The code I am working with has a python script that scans the subroutines and automatically generates the interfaces. Unfortunately the python script leaves the include statements in the interface and therefore I was facing with this nested interfacing issue. After fixing this issue in the python script, everything went smooth and I even observed that the compilation time reduced significantly. 

[jimdempseyatthecove]

Ahmad,

Perhaps you can post your Python script for others to use. Some readers of this thread may find it useful.

Jim Dempsey