Numerical differences between v11.1 and v13.0

Numerical differences between v11.1 and v13.0


We're just trying to upgrade our Intel Composer installation from 2011 to 2013, but we are finding that although most results are unchanged, a few change a bit, and some quite a lot.

I've read through the release notes, and what I understood would not explain these differences (we have no multi-threading or classes - polymorphic or otherwise).


Are there any difference between the Intel Fortran compiler v13.0 and its immediate predecessor v11.0 in the following areas:

  • Are uninitialised variables treated differently?
  • Are there any compiler flags (like floating point settings) whose defaults have changed?
  • Has the implicit casting of numeric types changed?
6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.


Mike S. wrote:
Are uninitialised variables treated differently?

By default, such variables are not "treated". Instead, the consequences of their being present "happen" and are quite unpredictable. If you suspect that variables are being used without initialization, you will have to track them down. There is limited support for automatically detecting them.

In C++ there're static analysis tools which are pretty good at identifying uninitialised variables (as do the compiler warnings).  I'm experimenting with a few of the Fortran ones, but the quality is pretty poor in comparison.  The only differences I could imagine is something like all REAL values being initialised by the compiler to being DBL_MAX instead of being left as random memory, but I agree it's a long shot!

You can try compiling your code with various diagnostics (/warn:declarations, etc.) and turn on various run-time checks (/check:uninit, etc.) to investigate your code.  You can also try static-analysis features in Intel Fortran if your license includes more than just the compiler, or look at free-ware utilities such as ftnchek at

There are two IFort options, /Qzero and /Qsave, which can be useful to strengthen a suspicion that a user program is affected by uninitialized variables.

It has been my experience that hunting down uninitialized variables, and other bugs in general, is far easier to do with Fortran code than with C code. C offers more ways to screw things up than Fortran does, and one has to weigh that property against the closer-to-the-machine features of the C language.

Thanks, mecej4 and FortranFan - I've had another look at those Fortran options, and they should definitely give us a lead.

Leave a Comment

Please sign in to add a comment. Not a member? Join today