Strange behavior in memory analysis

Hi all,

I have run a memory analysis (the widest scope memory analysis type) via Inpsector XE 2013. It includes analysing of stack acceses, to cach uninitialized arrays/variables.

Attached is a PNG figure with the results.

Note the strange behavior in Polar_HUCM.F90 module, which imply there is uninitialized memory access in line 119. However, note that line 120 is identical in terms of using the same arrays and specifically the same part of the array being controlled by "kb" loop.

Passing Parts of Derived Data Type to Subroutine

I am building a subroutine that I can either use a derived data type (my preference) or individual arrays.

The arrays will be passed to a various subroutines, including the MKL CG Solver.  My question is will this form temporary arrays or will the compiler efficiently use the arrays in the routines (particularly in MKL)


Bellow are is an example (forgive any minor bugs as I am just typing this from the window to illustrate what I mean)

Unformatted file I/O difference between Debug and Release

I have code which has the option of dumping memory to a file and then later reading this file to repopulate memory for a later run.  I am noting that I can run the code in Release mode without error, and yet in Debug mode the READ statements crash with the claim, input beyond end of record.

The READ statements contain within the program two REWIND statements for the file.  I have put some tracking statements to a file to see where the problem lies, but there is no apparent reading out of sequence.

Intel Inspector XE stack traces with C++ code

We are evluating Inspector XE 2015 and have version:
  Update 1 (build 379161)
When working with C++ compiled with the Visual Studio 2013 compiler inspector gives stack traces to memory or gdi leaks
with names like:


whereas we would expect to see C++ class names included:


historical question

I was recently explaining to a colleague why I chose Intel Fortran for a legacy application that will (assuming we receive the expected funding) undergo a modernization process.  I was missing one historical piece of information.  I know that Intel Fortran is descended from DEC Fortran.  But there is also an HP Fortran, which supports HP's proprietary operating systems, including (Open)VMS.  Was there a point at which a single compiler diverged into the two products we see today?  Is there still sharing of effort/code among the two companies?



Unknown option -xSSE4.2

Hi all,

I am trying to compile a fortran code using ifort (version 10.1) in a linux machine (ia64) as follows

ifort -c -O3 -xSSE4.2 -ip my_code.f90

and I am getting the following warning

ifort: command line warning #10006: ignoring unknown option '-xSSE4.2'.

Could anyone give me a hint to avoid this warning?

(Although I could get the executable by compiling the code without the '-xSSE4.2' option, when I execute it, it stops with segmentation fault !!!)


#6375: Because of COMMON, the alignment of object is inconsistent with its type

I have one of a very common issue. But I am not sure why it happens this time. 

Warning #6375: Because of COMMON, the alignment of object is inconsistent with its type[P]




Using . instead of % as a component selector tool for a derived type


I accidently used the period operator (.) instead of % as a component selector tool in my Fortran code. This seemed to work perfectly fine with the Intel Parallel XE 2015 compiler. However, I could not find it documented anywhere as being a safe alternative for the % character. Is this a known feature or change to the standard?

I personally find it easier to read code with the period operator and would like to adopt this as a standard code-writing practice. Any suggestions or warnings will be welcomed.

S’abonner à Fortran