IFORT crashes Visual Studio 2019 while building library, release version only

[AONym]

My project is C++, with the Fortran in a library. Building a release version of the library has started crashing Visual Studio 2019 16.11.5 (the latest VS2019 version).

What I see is, the build or rebuild of the Fortran library proceeds to "Creating library...", then VS2019 becomes unresponsive (Task Manager shows CPU ~5% on a 36-core machine) for a few minutes, then Visual Studio closes and restarts.

This does not happen every time, but it has started to occur on ~1/2 build attempts. There is no problem building a debug version (so far).

This is Intel Fortran Compiler – toolkit version: 2022.1.0, extension version 22.0.0065.16.  It is running under 64-bit Windows 10, with 256 GB of memory and plenty of free disk space.

[jimdempseyatthecove]

Does Project Only Release Rebuild of your Fortran library (IOW not the Solution rebuild) succeed?

This can determine if the issue is related to the Fortran project alone, or due to the dependency walker between projects in the solution.

IIF the Project Only Release Rebuild of your Fortran library succeeds, then see if your build dependencies have a circular reference.

Jim Dempsey

[AONym]

Jim: You asked "Does Project Only Release Rebuild of your Fortran library (IOW not the Solution rebuild) succeed?"

The answer is, no. Release Rebuild, of the Fortran library only, crashes VS after a few minutes of unresponsiveness.

If instead of a complete rebuild, I do a build that just compiles a single file that I have changed, it usually works. And, as I said, a debug build always works.

It is entirely possible that the Fortran library has some circular dependencies. Is there any tool that can test for this? Is there any compiler option to check?

[jimdempseyatthecove]

>>It is entirely possible that the Fortran library has some circular dependencies. Is there any tool that can test for this? Is there any compiler option to check?

Not that I am aware of.

>>Release Rebuild, of the Fortran library only, crashes VS

The usual suspect of this (barring compiler bug) is circular references of modules. Module A depends on module B, module B on module C, module C on module A. That type of thing. Sometimes this is caused by an unneeded USE, and other times it is a "legitimate" USE. In the sense that "legitimate" means you need access to the other module's data/contained procedures. In the "legitimate" case, you may need to reorganize the code/data or separate some code/data into additional module.

In one solution I have, I found it easiest to separate the data of a module from the contained code of the module (in separate files).

e.g mod_foo.f90 and mod_foo_code.f90

Jim Dempsey

[jimdempseyatthecove]

Oh, one more thing.

Avoid using a "compendium" module. IOW a single module that USE's all other modules that you use in each other module (to avoid explicit list of required USE statements).

Jim Dempsey

[jimdempseyatthecove]

Second more thing:

The default behavior of the ifort compiler is to enable inter-file IPO (which includes intra-file IPO). While you can eliminate circular dependencies as discussed earlier, there is an additional troublesome behavior related to IPO. This is/was/can be when there is a recursive path to the IPO. Note, while at run time the recursive execution path would be limited in depth, this is not the case at compile time. While I am NOT saying that the compiler design team did not take this into consideration (by detecting and limiting recursion of IPO), this does not preclude an exception scenario that exhibits infinite recursion at compile time.

To test/correct for this: (remember to perform full clean before each step)

1) Disable IPO. If this solves the problem .and. you desire a measure of IPO, then

2) Enable intra-file (single file) IPO.

If 2) solves the problem .and. you desire a measure of IPO, then

2.a) On a file by file basis: Right-click on the file in the project of the solution and then set the property for that individual file to inter-file IPO. If that succeeds to build, then perform 2.a) on next file. Or, if the build fails, disable inter-file IPO for this file (leaving intra-file IPO enabled). Repeat this process for all files (you deem appropriate for IPO).

If 2) Fails to solve the problem .and. you desire a measure of IPO, then

2.b) Disable intra-file IPO for the Project.

2.c) On a file by file basis: Right-click on the file in the project of the solution and then set the property for that individual file to intra-file/single file IPO. If that succeeds to build, then perform 2.b) on next file. Or, if the build fails, disable intra-file IPO for this file (no IPO). Repeat this process for all files (you deem appropriate for IPO).

Jim Dempsey

[andrew_4619]

Jim, I use IPO but IPO is not enabled by default as far I can see.