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

Backward compatibility of *.mod, *.smod, *.obj, *.lib and *.dll files across Intel compiler versions

OP1
New Contributor II
620 Views

This post stems from an internal debate I had with colleagues this morning, and I would certainly appreciate if anybody (and somebody from Intel in particular) could chime in and bring some clarity.

The topic is rather thorny... but it is is particularly relevant for organizations that deal with the long-term maintenance of large source code bases, or with codes that have 3rd-party dependencies.

Let's narrow the scope of the question to a Windows code (for a given platform, say, 64-bit).

  1. Assume that some *.mod, *.smod files have been produced by Intel Fortran Compiler version M. Can these files be reused in a project built with Intel Fortran Compiler version N, with N more recent than M?
  2. Same question with *.obj files (assuming that the same compiling options are used).
  3. Same question with *.lib files (assuming that the same linking options are used).
  4. Same question with *.dll files.

My understanding is that both Intel (for the compilers) and Microsoft (for the VC++ redistributables, if the code being built has such dependencies) go to great lengths to guarantee backward compatibility of their products.

In other words, as long as N is more recent than any of the compiler versions used to produce those files, and as long as the latest VC++ redistributables are present on the build system, then a new code based on those legacy files can be built and run on that system.

Possible reasons that would prevent this from being the case are (1) bugs in the old versions of the compiler that have been corrected in the newer ones; (2) possibly, flags and options that were available in older versions of the compiler but that do not exist anymore in the newer versions.

 

Is my understanding correct? If yes, are there specific caveats / traps / pitfalls to be aware of?

0 Kudos
3 Replies
Steve_Lionel
Honored Contributor III
600 Views

It has been the position and goal of the Intel Fortran Compiler project that all of the things you mention are what I would call upward compatible, but it's what you asked - as long as you use a compiler, linker and run-time library at least as new as the one(s) used to build the older thing, it should work. There have been exceptions due to bugs (in the .mod format, specifically), and the release notes (when I wrote them) listed these even going back many versions. I don't see similar text in current release notes and the old compiler release note seem to have been taken offline (I can see PSXE release notes back to 2016, but not the Fortran compiler notes.)

I'll comment that this compatibility policy, which dates back at least to VAX FORTRAN in the late 70s, is not universal, even within Intel. Intel C++ and Intel MKL, for example, don't promise mixed-version compatibility. I don't speak for the current Intel Fortran team, but I would be very disappointed if they abandoned this.

0 Kudos
OP1
New Contributor II
569 Views

Thanks @Steve_Lionel for your answer. Maybe @Barbara_P_Intel can confirm your statement?

0 Kudos
Barbara_P_Intel
Moderator
555 Views

I checked with the Fortran compiler team and got this reply.

We provide backward compatibility of those files across versions. That’s been a foundational principle since day 1. BTW… this also applies if “old compiler == ifort” and “new compiler == ifx”.



Reply