Intel® Fortran Studio XE

Installer crashes, Website only works in Firefox


Downloaded Intel Fortran compiler for evaluation on OSX.

Mounted installer dmg, fired up installer - instant crash missing symbol _strnlen in /usr/lib/libSystem.B.dylib

not very good

Find out if any way to report this - no

Forum website does not work in Chrome - only Firefox

Not a performance suggesting purchase this software

xe14=>xe15 cause a SIGSEV (openmp)

When updating from ifort 14 to ifort 15 (15.0.2 to be precise), several bugs have appear in our programs (while it ran smoothly with ifort 14). One of them seems related to openMP : 

forrtl: severe (174): SIGSEGV, segmentation fault occurred

Image PC Routine Line Source 00007FF35F0F3961 Unknown Unknown Unknown 00007FF35F0F20B7 Unknown Unknown Unknown 00007FF362794692 Unknown Unknown Unknown 00007FF3627944E6 Unknown Unknown Unknown 00007FF36275518C Unknown Unknown Unknown

Fortran forrtl: severe (174): SIGSEGV, segmentation fault in derived type data

 "m.f90" :
  1 module typedef
  2 implicit none
  3 type::mytype
  4     integer::mn(2,2)
  5     complex(kind=8)::w
  6     integer,allocatable::sz(:)
  7 end type
  8 end module typedef
  9 subroutine mysub(mtp)
 10 use typedef
 11 implicit none
 12 type(mytype)::mtp(6)
 13 integer::lm
 14 complex(kind=8)::f0(6),f1(6)
 15 do lm=1,6
 16     write(*,*)"a",lm
 17     f0(lm)=mtp(lm).w
 18     f1(lm)=f0(lm)
 19 end do
 20 end subroutine

forrtl: severe (174): SIGSEGV, segmentation fault occurred

when I compiled my program m.f90 with command: "ifort m.f90" and then run it "./a.out", error occured as follows

a           1
 b           1
 c           1
 a           2
forrtl: severe (174): SIGSEGV, segmentation fault occurred,

I don't understand why

The following is my program m.f90:

Compiler Memory Errors

This isn't a problem, per se, but in trying to gather more information for one of the infamous "catastrophic internal errors", I ran ifort 12.0.0 (and its descendants) through valgrind.  ifort had several dozen memory access errors (mostly jump-based-on-uninitialized), and fortcom had over 1,000 errors reported (mostly use of uninitialized variables).  You guys might want to consider adding memory profiling tests to your pre-release software qualification suite.

List Directed I/O Error


As can be seen in the attached program, when I am trying to open, read and write data into an array, I am getting an error which says as follows:

"forrtl: severe (59): list-directed I/O syntax error".

Any suggestions or insight into this would be greatly helpful.

Thank you.

Memory not released after DEALLOCATE

 I am working as a software developer in a company with a code based on FORTRAN 90. Recently we have found that code was failing with lack of enough memory at some stage of the run. Tests have shown that using the "Deallocate" makes the pointers used "unassociated", but for some pointers the memory is not released. This could be a large amount causing the code to crash eventually. The situation becomes worse as we are allocating and deallocating the same pointers several times during the runtime.

error #6405: The same named entity from different modules and/or program units cannot be referenced.


I am getting the error message from the title when compiling the code in which there are many modules having the initialisation procedures with the same name, init. Normally, when the various modules use each other, I mask those init procedures with use somemodule, forgetme => init. However, intel fortran compiler 13.1.3 20130607 fails to compile it and, what is worse, it is not easy to say where exactly the error originates from, since it is issued from some temporary .i90 file the compiler made as it went about its business.

We now have the reverse problem with the Intel 15.0.1 compiler on RHEL6 x86_64: building a shared...

We now have the reverse problem with the Intel 15.0.1 compiler on RHEL6 x86_64: building a shared object with -shared but without -static-intel still results in the inclusion of libifcore_pic.a in the corresponding shared object. This is a problem because when later an OpenMP-enabled Fortran program wants to use the library, the incompatible run-times cause the binary to segfault at launch.

Is this already known? Should I prepare a test case?


Subscribe to Intel® Fortran Studio XE