Intel® Fortran Compiler

Inconsistent program behavior on RHEL* 7.4 or Fedora* 25 if compiled with Intel Compiler

We've seen some reports with regarding to RHEL7.4 OS and Fedora 25 that comes with glibc that has a change that Intel Compiler doesn't work well with. There're simple workarounds for the problem. Please see the following two KB articles for details.

Intel® Parallel Studio XE 2018 has been released!

Intel® Parallel Studio XE 2018, including Intel® Fortran Compiler 18.0, is now available from the Intel Registration Center. Release notes can be found here.

The Intel® Fortran Compiler now supports all features from the Fortran 2008 standard. Additional Fortran 2008 features added in the Intel® Fortran 18.0 release are noted below:
 

rc.exe not found

I have a piece of code that runs on another computer that I'm trying to compile and run on my computer but whenever I try to build the solution I get an error rc.exe not found. I've done some research and believe that the issue is related to having the wrong combination of Visual Studio and Intel Fortran installed together. I've tried uninstalling and reinstalling several different version of both VS and Parallel Studio, ranging from 2013 - 2017 but I have not had much luck.

Оптимизировали, оптимизировали, да не выоптимизировали!

Оптимизация? Конечно, каждый сталкивался с данной задачей при разработке своих, сколь-нибудь значительных, требующих определённых вычислений, приложений. При этом способов оптимизировать код существует огромное множество, и, как следствие, различных путей сделать это в автоматическом режиме с помощью опций компилятора. Вот здесь и возникает проблема – как выбрать то, что нужно нам и не запутаться?

ifort 18 regression: segfault on ALLOCATE with SOURCE (using -qopenmp or -recursive)

Hi all,

we just stumbled upon another regression of ifort 18 (in fact this is already the third one I'm aware of). Consider this simple test case:

program alloc_w_source

   type T
      integer, dimension(:), allocatable :: vals
      integer :: k = 3
   end type

   type(T), dimension(:), allocatable :: x

   allocate(x(1:8), source=T())

end

Compiling this with "ifort -qopenmp" or "ifort -recursive" and running the generated executable produces a runtime segfault, which is obviously a compiler bug. Valgrind shows:

C-Fortran callback interoperability with c_funptr not giving correct output

Hi.

I am working with some Fortran - C code for passing C functions to Fortran subroutines or functions (I am interested in both).  I came across this example using the gnu compiler, and I have verified that the example works (attached both source files).  But the example does not work with the intel fortran compiler (2018, running on opensuse linux).  Instead of the given argument (c_double type) being displayed, a value of 0.00000... is displayed.

Problem when using OpenMP SIMD with subroutine inlining (possible compiler bug)

Hi all,

I am experiencing some strange behavior when I use the OMP SIMD directive in a couple of loops with inlined subroutines and I am getting more and more convinced that this might be a bug in the compiler. If it is not, I would be really thankful if someone could point me to the error in my code.

Request for links to lists of bug fixes

Hi,

I was wondering if it was possible to add the link to the lists of bug fixes for each version of the compiler as Sticky post in this forum.

This will greatly improve the user experience to have a centralized location to search for reported bugs.

Each time a new version of the compiler is release, a new message could be created on this post with the link to the URL containing the list of bug fixes.

I found the following page related to v16 and v17:

订阅 Intel® Fortran Compiler