Unable to install the Fortran(x64)

I have install Visual studio 2008 on my computer and now I want to install the fortran (X64). However, the installation failed and I got the following message:

"Unable to install the integration into Visual Studio. Failure in"C:\\program files (86)\Microsoft Visual Studio 9.0\IntelFortran \VFPackages\integrate.bat" "c:\\program files(86)\Microsoft Visual Studio 9.0\Common7\Tools" (see picture)

Different results with -O0 -openmp or -O3 -openmp

Hi all, 

I developed a FORTRAN (F90) code (its a large model) with the following compilation flags :

ifort -g -O0 -openmp -openmp_report -threads -ipo

When running this code with the above flags, I keep the results within 15 digits after the dot when running serial or parallel (OpenMP). I have also checked with Intel Inspector 2013 - and I do not have any data race condition in either if the subroutines.

OpenMP or optimization changed from to

Dear Experts in OpenMP and Intel C  14.x ,

Until version 13.x of Intel C I had the following code :

static  int   fobj_offset(int m, double *a, double *fun)


      int     n = npivot;

      double  *p = ppivot;

      int     i;

      double  cen[3*n];

      double  x=0.0,y=0.0,z=0.0;

      double  err=0.0;

      Tool_Point_Offset[0] = a[0];

      Tool_Point_Offset[1] = a[1];

      Tool_Point_Offset[2] = a[2];

Fail to link 64-bit Code

I have a working 32-bit software library written in Fortran with low-level stuff in C/C++ It has worked for years.

It is fine.

When I re-build the library in 64-bit mode, none of the C functions are linked in. I've checked the linker options, and they all seem to be right. The project appears to be referencing the 64-bit libraries.

Would someone mind just looking some sample  INTERFACE code and tell me whether there is anything at all that would cause a problem 


This is just a general question for peoples opinions on the VALUE attribute used in subroutines. I know it The VALUE attributie is sometimes necessary for interoperability with C, but my interest is what would be the benefit beyond that compared to INTENT(IN). I am assuming  that it makes no sense to have both at the same time.


Below is a simple example of what I am talking about

  REAL,      VALUE::X


inconsistent treatment of TYPE vs. REAL in 'stream' write with Intel big-endian I/O conversion

I'm seeing different bit patterns when I write a REAL variable to file as component of a TYPE as opposed to when it's just a REAL in stream output while using the -convert big_endian option.

Given the following small program, which opens a file in 'stream' access mode and the proceeds to write two REAL's:

$ cat stream-write.f90
  TYPE bar
    real :: x
  END TYPE bar
  INTEGER, PARAMETER :: file_id = 20
  INTEGER :: ierror
  REAL :: y
  TYPE(bar) :: z

braced-init-list in ranged for loop is not supported (C++11)?

Hi, according C++11 specification (in my case I refer to draft n3376) the following 'for' construction is valid:

#include <iostream>
int main(void) {
    for (auto x : { 0, 1, 2 }){
        std::cout << x;

But trying to compile it with intel c++ compiler gives me error:

main.cpp(3): error : assertion failed at: "shared/cfe/edgcpfe/il.c", line 15066

I have installed the following compiler: Intel® C++ Composer XE 2013 SP1 Update 2 Integration for Microsoft* Visual Studio* 2013, Version 14.0.1290.12

Deferred length string component: segmentation fault

In a project I am working on, I changed a fixed length string in a structure within a module to a deferred length string and the result was an internal compiler error (the code compiled and ran without issue before the change).  I cannot reproduce the internal compiler error with a simple case, but I do get a segmentation fault in the below program when it hits the WRITE() statement.  It is unclear to me what the issue is or if this is even related to the internal compiler error I was trying to reproduce.  When compiling with '-std03', I get "warning #5436: Overlapping storage initializatio

Format label and Contains block

Hi all,

i'm working on a main routine with many other subroutine in a contains block. In the main one, I defined some format labels but I can't use them in the contains block : they are no more defined. At the moment, I avoid this problem by redefined format labels in each subroutine in the contains block ; but this solution isn't really suitable. Is there a way to define these labels only once ?



Subscribe to Compilers