Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28385 Discussions

Modules with many interface blocks take a long time to compile

Mitterfellner__Thoma
272 Views
I'm compiling a fortran project using Intel Fortran compiler 16 under RHEL Linux 6.8. In this project, I have several module files containing only interface blocks of routines (I'm using these similar to the function of C/C++ header files), and I add USE statements with ONLY clauses for the appropriate routines in the routines I'm calling them from in order to circumvent the error 8055 (The procedure has a dummy argument that has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE or VOLATILE attribute. Required explicit interface is missing from original source). Now when I have a module file declaring, say, ~80 interfaces to subroutines, this file takes a very long time to compile compared to, e.g., a whole module file with several thousands of lines of 'ordinary' source code. It seems to help a little bit to split them up into several submodules inside of the module file like this (as opposed to having all interface in one module block):
MODULE MY_MOD_1
   INTERFACE
      ...
   END INTERFACE
END MODULE MY_MOD_1

MODULE MY_MOD_2
   INTERFACE
      ...
   END INTERFACE
END MODULE MY_MOD_2
...

MODULE MY_MAIN_MOD
   USE MY_MOD_1
   USE MY_MOD_2
   ...
END MODULE MY_MAIN_MOD
My questions are now: Why does it take so long to compile simple interface blocks (should I file a bug report?) and is there any way to speed that procedure up? N.B.: I know the 'proper' solution would be to move the routines requiring interfaces to module files but that is, unfortunately, not possible as that would mean grave changes to the structure of the historically grown code base
0 Kudos
4 Replies
Kevin_D_Intel
Employee
272 Views

Nothing current in terms of a previous defect report comes to mind from your description. Past issues of long-compile time (now fixed) involved nesting of modules, so perhaps yours has a similar relationship. So yes, if you can submit a complete reproducer, including all the source necessary to reproduce the lengthy compilation, that would enable Development to investigate further and perhaps offer a work around.

If there’s concerns with posting source code in the public eye in this forum then please submit an issue through our Online Service Center.

Online Service Center FAQ

0 Kudos
Mitterfellner__Thoma
272 Views
Kevin D (Intel) wrote:

Past issues of long-compile time (now fixed) involved nesting of modules, so perhaps yours has a similar relationship. So yes, if you can submit a complete reproducer, including all the source necessary to reproduce the lengthy compilation, that would enable Development to investigate further and perhaps offer a work around.

Unfortunately, I cannot provide a reproducer. But concerning the nesting of modules: what exactly do you mean by this? And in which version would that be fixed? The module in question does depend on the types declared in other modules and those modules partially also depend on other modules. Is this what you mean by "nesting"? The module containing other modules is a workaround devised by a co-worker of mine; it brings compilation time for this file from >5 minutes (maybe ~10) down to about forty seconds, which is still unusually long, IMO. I have several of these files only containing interface declarations, and compilation time has increased substantially since I introduced them.
0 Kudos
jimdempseyatthecove
Honored Contributor III
272 Views

Try disabling Interprocedural Optimizations between files (option -ipo-). You can do this for selected files or the entire project.

Jim Dempsey

0 Kudos
Kevin_D_Intel
Employee
272 Views

Yes, a nesting via USE statements as generally described here. Fixes for reported cases were available in the PSXE 2015/2016 (ifort 15.0/16.0) releases. I inquired w/Developers if they are aware of other cases relating to your code description.

0 Kudos
Reply