Intel® Fortran Studio XE

PASS attribute and parameterized derived types


I get the following error when I compile pass_pdt.f90 (attached):

pass_pdt.f90(28): error #8262: For a type-bound procedure that has the PASS binding attribute, the first dummy argument must have the same declared type as the type being defined.   [VAL]
  SUBROUTINE testq(val, this)

I explicitly attach the pass attribute to the second argument, this, and not the first. The second attached file (pass.f90) has no such issues. The only difference is that the derived type is no longer parameterized. Is this a compiler bug?

creating a batch file within FORTRAN

I have a set of output files that are created by a FORTRAN program in a directory, with which I would like to perform a set of operations such as copy, rename, and execute another FORTRAN executable using these output files as the arguments, all in a batch mode. Is there a way in FORTRAN to perform all this operations together in one FORTRAN program? Thank you in advance for any help/suggestions in this regard.


Bug with USE renaming, inlining, and optimization report

I believe I found a bug with the Intel 15.0 compiler where a USE-renamed subroutine shows up in the optimization report under the USE-renamed name, rather than the subroutine's actual name.  I'm not sure if this is the compiler's intended behavior, but it seems unnecessarily confusing.  Consider the code:

Performance problem between ifort 12.1 and ifort 15.0 on the same code


I compile the following small code with "-O3 -shared-intel" on  three different clusters:

  • cluster1: Intel(R) Xeon(R) CPU X5675 with ifort 12.1.0
  • cluster2: Intel(R) Xeon(R) CPU X5650 with ifort 12.1.0
  • cluster3: Intel(R) Xeon(R) CPU E5-2650 v2 with ifort 15.0.0


Format syntax error

In my application I obtain a format syntax error, but I  do not recognize why.

I created a minimal example:

program test
  implicit none
  character(len=200) :: formatstr
  character(len=*), parameter :: formatstr2 = '("test",I2.2,"")'

  formatstr = formatstr2
  write(*,'(A)') formatstr
  write(*,'(A)') formatstr2
  write(*,*) formatstr == formatstr2
  write(*,formatstr2) 12
  ! the next line creates an error
  write(*,formatstr) 12

end program test

I obtain the following output:

Run-time error when opening/reading an ASCII file



I am compiling a large program, which depends on several external Fortran and C libraries, on a Mac OS X 10.9.5 with Intel Fortran Compiler 15.0.1. I get a run-time error when opening an external (ASCII) file and reading it. The strangeness is that the file exist (inquired form within the program) and the that calling open gives a status = 0 (see the test program below).The simple test program below compiles and runs well on gfortran, while with ifort it gives a runtime error, which I reported below (including the backtrace, as given by gdb).

Intel Ifort 15 + OpenMPI 1.8.4 + OpenMP= instantaneous segfault


using Intel ifort 15, I compiled OpenMPI 1.8.4 using the following configure line:

../configure --prefix=<path to installdir>  --with-openib --with-sge CC=icc FC=ifort CXX=icpc

Unfortunately, compiling our hybrid MPI + OpenMP code with the resulting MPI compiler wrapper results in a binary which segfaults instantaneously after startup.

Please consider the following example which shows the same behavior as our large code: destabilizes my linux environment


I have tried to install Intel Composer XE 2015.0.090 in both OpenSuse 13.1 and Ubuntu 14.04 LTS environments. In both cases I have followed the instructions here (  and installed the compilers for 64bit system only.

When I add the

source /opt/intel/bin/ intel64 

Incorrect result with COUNT in initialization expression

I found that Intel Fortran 15 gives incorrect results with the COUNT intrinsic in initialization expressions. Consider the following program:

program count_bug
  implicit none

  integer, parameter :: npts(2) = (/ 42, 1 /)
  integer, parameter :: ndims = count(npts .gt. 1)

  write (*,'(2(I0, 1X))') count(npts .gt. 1), ndims
end program

When compiled with ifort, the output is "1 -1".  The correct output is "1 1".

This result was obtained with Intel Fortran 15.0.1 20141022 on Mac OS X 10.10.1.

Subscribe to Intel® Fortran Studio XE