Increasing the size of the interface/contains stack

[btrettel]

Is there a way to increase the size of the interface/contains stack in ifx? It would take a while to explain why, but I have a Fortran code which generates a Fortran module containing a ton of types with type-bound operators and associated functions. With ifx 2024.1.0 on Ubuntu 20.04 LTS, when I exceed about 800 functions generated with about 30 associated types, I get the following error when compiling a program using my generated module (but not when compiling the module itself):

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

There are no circular dependencies, so I think the actual problem is the size of my module. I do not necessarily mind slow compilation here, so if there is a way to increase the size of the interface/contains stack, I'm interested. (For what it's worth, ifx and gfortran compile the module far faster than nvfortran.)

If there is no way to increase the size of the interface/contains stack, what is the precise limit for the interface/contains stack and what exactly should I be counting in my generator to avoid hitting the limit? I am looking into ways to reduce the number of generated types and functions to do what I want to here, but I don't yet have a good solution.

(If I should not be seeing this error with ~800 functions, let me know and I can post a reproducer.)

Thanks.

[jimdempseyatthecove]

Would sub-modules avoid the error? (This would place the code in different source files)

Jim Dempsey

[btrettel]

Good idea. All I can say is maybe at the moment because I don't know what ifx is doing under the hood. But breaking the module up into submodules might work. I'll try it.

[Steve_Lionel]

There is no user control over the size of the compiler's internal data structures.

[jimdempseyatthecove]

A possible alternative is to disable IPO. I believe single file IPO is on by default, disabling this may reduce the internal compile storage requirements.

Jim Dempsey

[Steve_Lionel]

I'm skeptical that IPO is involved here, as this is a "front-end" message I have seen before.  I have routinely compiled modules with thousands of interface blocks (the Windows API modules) so I'm unsure if the size of the module itself is an issue. Please attach a reproducer if you can.

[btrettel]

I've attached a zip file containing a reproducer. Included are 3 different versions of the module of varying sizes:

• pdim_12.f90: 12 types, 170 functions (compiles both the module and program)
• pdim_30.f90: 30 types, 837 functions (fails to compile the program, but compiles the module)
• pdim_50.f90: 50 types, 2205 functions (fails to compile the program, but compiles the module; included in case pdim_30.f90 compiles fine on you all's end as this probably won't compile)

Here's a command line log showing what I see:

$ ifx --version
ifx (IFX) 2024.1.0 20240308
Copyright (C) 1985-2024 Intel Corporation. All rights reserved.

$ uname -a
Linux trident 5.15.0-105-generic #115~20.04.1-Ubuntu SMP Mon Apr 15 17:33:04 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
$ ls
pdim_12.f90  pdim_30.f90  pdim_50.f90  test_pdim_types.f90
$ time ifx pdim_12.f90 test_pdim_types.f90 

real    0m0.499s
user    0m0.386s
sys     0m0.113s
$ ./a.out 
  0.000000000000000E+000
   2.00000000000000     
  -1.50000000000000     
  0.500000000000000     
   2.00000000000000     
   3.00000000000000     
   16.0000000000000     
$ rm a.out pdim_types.mod 
removed 'a.out'
removed 'pdim_types.mod'
$ time ifx pdim_30.f90 test_pdim_types.f90 
test_pdim_types.f90(18): error #6618: The INTERFACE/CONTAINS stack is full. This means that modules are being 'used' in a circular way.
x%v = 1.0_WP
^
compilation aborted for test_pdim_types.f90 (code 1)

real    0m2.346s
user    0m2.119s
sys     0m0.227s
1 trident$ rm a.out pdim_types.mod 
rm: cannot remove 'a.out': No such file or directory
removed 'pdim_types.mod'
1 trident$ time ifx pdim_50.f90 test_pdim_types.f90 
test_pdim_types.f90(18): error #6618: The INTERFACE/CONTAINS stack is full. This means that modules are being 'used' in a circular way.
x%v = 1.0_WP
^
compilation aborted for test_pdim_types.f90 (code 1)

real    0m15.114s
user    0m14.627s
sys     0m0.482s

For comparison, gfortran compiles all of these fine, and fast too.

To be clear, all of these modules are generated by another Fortran program. As far as I'm aware, the generated modules are valid Fortran, though the generated modules are unusually large. So I am not surprised to run into issues compiling and maybe even run into some hard-coded compiler limits. I'm not sure there is a bug in ifx, but please take a look and let me know. If my code is doing anything wrong, let me know too. If it might help, I can explain what I'm trying to do here as well.

(Also: Trying `-no-ipo` did not help here.)

[jimdempseyatthecove]

FWIW: This means that modules are being 'used' in a circular way.

The fact that one compiler can compile your code is no confirmation that your code's module usage is not circular.

Intel, it would be helpful, when you emit this error, that you include a stack dump of the USE contexts. This would identify where the circular references are located (when this be the cause) or provide feedback to Intel developers about a non-circular reference issue.

Jim Dempsey

[Steve_Lionel]

I reproduced the problem without IPO in ifort. NAG Fortran builds all three versions quite quickly.

[Ron_Green]

It's a bug in our front end.  We'll get it fixed.