I use Intel Parallel Studio XE 2013 with Visual Studio Shell. I'm trying to compile fortran code with openmp with static linking. It compiles and produces executable. But the executable does not work on another computer because of missing libiomp5md.dll file. I have used  /MT /Qopenmp-link:static command line for both fortran compile and linker options but it does not generate fully static compiled executable. Is there any way to fix this problem?

Thanks in advcance.

Module mytype_module
!Example taken from "Fortran 95/2003 explained," by Metcalf, Reid, Cohen, Page 280;

!IFORT 16.0.0 compilation fails with
!"error #6074: The number of actual arguments does not match the definition.   [WRITE]"
!when the passed-object argument follows an absent optional argument

!It seems to me that
!              call x%write
!is implemented as
!            call write_mytype(x),
!instead of
!          call write_mytype(this = x),
!which could explain the compilation failure

   Use iso_fortran_env, Only: output_unit
   Implicit None

   Type mytype
      Real :: myvalue(4) = 0
   Contains
      Procedure, Pass(this) :: write => write_mytype
   End Type mytype

   Private :: write_mytype
Contains

   Subroutine write_mytype(unit, this)
      Integer, Optional         :: unit
      Class(mytype), Intent(In) :: this

      If(Present(unit)) Then
         Write(unit, *) this%myvalue
      Else
         Print '(4f6.3)', this%myvalue
      End If
   End Subroutine write_mytype

End Module mytype_module

Program test
Use mytype_module
   Implicit None

   Type(mytype) :: x = mytype((/1, 2, 3, 4/))

                               !WAY to make IFORT compile:
   Call x%write                !comment out this line and
   !Call x%write(output_unit)  !uncomment this, so as to provide the
                               !optional argument

End Program test

Hello,

First off, my compiler and some platform details:

$ ifort --version
ifort (IFORT) 16.0.1 20151021
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

$ uname -a
Linux tfe04 2.6.32-431.29.2.el6.x86_64 #1 SMP Sun Jul 27 15:55:46 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux

(It's a login node of a supercomputer)

I have an example of some code (shown below) that does not compile, exhibiting error #6866 which, based on my searches of these forums, should have been fixed in an earlier version.

MODULE my_define
  IMPLICIT NONE
  PRIVATE
  PUBLIC :: my_type

  TYPE :: my_type
    INTEGER :: j = 0
    INTEGER :: i = 0
  CONTAINS
    PRIVATE
    PROCEDURE :: Equal
    PROCEDURE :: NotEqual
    PROCEDURE :: Compare
    GENERIC, PUBLIC :: OPERATOR(==) => Equal
    GENERIC, PUBLIC :: OPERATOR(/=) => NotEqual
    GENERIC, PUBLIC :: OPERATOR(.Compare.) => Compare
  END TYPE my_type

CONTAINS

  ELEMENTAL FUNCTION Equal( x, y ) RESULT( is_equal )
    CLASS(my_type), INTENT(IN) :: x, y
    LOGICAL :: is_equal
    is_equal = (x%j == y%j) .AND. (x%i == y%i)
  END FUNCTION Equal


  ELEMENTAL FUNCTION NotEqual( x, y ) RESULT( not_equal )
    CLASS(my_type), INTENT(IN) :: x, y
    LOGICAL :: not_equal
    not_equal = .NOT. (x == y)
  END FUNCTION NotEqual


  FUNCTION Compare( x, y ) RESULT( is_equal )
    CLASS(my_type), INTENT(IN) :: x, y
    LOGICAL :: is_equal
    is_equal = .TRUE.
    IF ( x%j /= y%j ) THEN
      print *, 'J component of my objects are different'
      is_equal = .FALSE.
    END IF
    IF ( x%i /= y%i ) THEN
      print *, 'I component of my objects are different'
      is_equal = .FALSE.
    END IF
  END FUNCTION Compare

END MODULE my_define



! =======================
! Test program for module
! =======================

PROGRAM Test_my
  USE my_define, ONLY: my_type
  IMPLICIT NONE

  LOGICAL :: is_equal
  TYPE(my_type) :: my, my_copy

  my%j = 1
  my_copy = my
  IF ( my /= my_copy ) THEN
    is_equal = my .Compare. my_copy
  END IF
END PROGRAM Test_my

When I compile the above I get:

$ ifort one_type.f90
one_type.f90(67): error #6866: Dotted string is neither a defined operator nor a structure component.   [COMPARE]
    is_equal = my .Compare. my_copy
-------------------^
compilation aborted for one_type.f90 (code 1)

As far as I can tell, my test code is correct and standard conforming. Am I missing something?

The same code builds and runs fine using gfortran 4.9.x

Thanks for any information

cheers,

paulv

I am working on Mac OS X 10.11.2, under bash.

After installing Fortran 2016 I tried to set the environment variables as follows:

source /opt/intel/bin/compilervars.sh intel64

I obtained the following message:

bash:  /opt/intel/bin/compilervars.sh: line 130: syntax error: unexpected end of file

What could be the problem ? Thanks in advance.

We have installed fortran on 22Dec 2015 in our server

Fortran compiler worked fine until 22Jan 2016

After that we are getting error : Error: A license for FComp is not available (-5,357).

ifort: error #10052: could not checkout FLEXlm license

We have taken a permnant license , even though we are having this error

Can anyone please help how to check fortran compiler license OR resolve this issue

Thanks ,

Raghu

Ifort complains that the name `node` inside the interface body for `two` isn't a type.  I think it is getting confused by the use of `node` as a dummy argument in the previous interface body.

MODULE m
  IMPLICIT NONE

  TYPE :: Node
  END TYPE Node

  INTERFACE
    MODULE SUBROUTINE one(node)
      INTEGER :: node
    END SUBROUTINE one

    MODULE SUBROUTINE two(arg)
      TYPE(Node) :: arg
    END SUBROUTINE two
  END INTERFACE
END MODULE m

>ifort /check:all /warn:all /standard-semantics "2016-01-25 node.f90"
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0 Build 20151021
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

2016-01-25 node.f90(13): error #6463: This is not a derived type name.   [NODE]
      TYPE(Node) :: arg
-----------^
2016-01-25 node.f90(12): warning #6717: This name has not been given an explicit type.   [ARG]
    MODULE SUBROUTINE two(arg)
--------------------------^
compilation aborted for 2016-01-25 node.f90 (code 1)

Hello,

Again, my environment:

$ ifort --version
ifort (IFORT) 16.0.1 20151021
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

$ uname -a
Linux tfe03 2.6.32-431.29.2.el6.x86_64 #1 SMP Sun Jul 27 15:55:46 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux

I believe the linux is a flavour of Red Hat (RHEL6 I think).

I discovered what I think may be a minor compiler bug due to my overuse of PRIVATE statements in object definitions. Note the use of the PRIVATE statement in the CONTAINS section of the iVar_type object definition below:

MODULE my_define
  IMPLICIT NONE
  PRIVATE
  PUBLIC :: my_type

  ! Contained object definition
  TYPE, PRIVATE :: iVar_type
    INTEGER :: i = 0
  CONTAINS
    PRIVATE  ! *** This is the statement in question ***
    PROCEDURE :: iVar_Equal
    PROCEDURE :: iVar_NotEqual
    PROCEDURE :: iVar_Compare
    GENERIC :: OPERATOR(==) => iVar_Equal
    GENERIC :: OPERATOR(/=) => iVar_NotEqual
    GENERIC :: OPERATOR(.Compare.) => iVar_Compare
  END TYPE iVar_type

  ! The main object definition
  TYPE :: my_type
    INTEGER :: j = 0
    ! Contained object
    TYPE(iVar_type) :: iVar
  CONTAINS
    PRIVATE
    PROCEDURE :: Equal
    PROCEDURE :: NotEqual
    PROCEDURE :: Compare_
    GENERIC, PUBLIC :: OPERATOR(==) => Equal
    GENERIC, PUBLIC :: OPERATOR(/=) => NotEqual
    GENERIC, PUBLIC :: OPERATOR(.Compare.) => Compare_
  END TYPE my_type

CONTAINS

  ELEMENTAL FUNCTION Equal( x, y ) RESULT( is_equal )
    CLASS(my_type), INTENT(IN) :: x, y
    LOGICAL :: is_equal
    is_equal = (x%j == y%j) .AND. (x%iVar == y%iVar)
  END FUNCTION Equal

  ELEMENTAL FUNCTION iVar_Equal( x, y ) RESULT( is_equal )
    CLASS(iVar_type), INTENT(IN) :: x, y
    LOGICAL :: is_equal
    is_equal = (x%i == y%i)
  END FUNCTION iVar_Equal


  ELEMENTAL FUNCTION NotEqual( x, y ) RESULT( not_equal )
    CLASS(my_type), INTENT(IN) :: x, y
    LOGICAL :: not_equal
    not_equal = .NOT. (x == y)
  END FUNCTION NotEqual

  ELEMENTAL FUNCTION iVar_NotEqual( x, y ) RESULT( not_equal )
    CLASS(iVar_type), INTENT(IN) :: x, y
    LOGICAL :: not_equal
    not_equal = .NOT. (x == y)
  END FUNCTION iVar_NotEqual


  FUNCTION Compare_( x, y ) RESULT( is_equal )
    CLASS(my_type), INTENT(IN) :: x, y
    LOGICAL :: is_equal
    is_equal = .TRUE.
    IF ( x%j /= y%j ) THEN
      print *, 'J component of my objects are different'
      is_equal = .FALSE.
    END IF
    IF ( x%iVar /= y%iVar ) THEN
      print *, 'iVar component of my objects are different'
      is_equal = .FALSE.
    END IF
  END FUNCTION Compare_

  FUNCTION iVar_Compare( x, y ) RESULT( is_equal )
    CLASS(iVar_type), INTENT(IN) :: x, y
    LOGICAL :: is_equal
    is_equal = .TRUE.
    IF ( x%i /= y%i ) THEN
      print *, 'I component of iVar objects are different'
      is_equal = .FALSE.
    END IF
  END FUNCTION iVar_Compare

END MODULE my_define



! =======================
! Test program for module
! =======================

PROGRAM Test_my
  USE my_define, ONLY: my_type
  IMPLICIT NONE

  LOGICAL :: is_equal
  TYPE(my_type) :: my, my_copy

  my%j = 1
  my_copy = my
  IF ( my /= my_copy ) THEN
    is_equal = my .Compare. my_copy
    print *, 'objects are not equal'
  ELSE
    print *, 'objects are equal'
  END IF
END PROGRAM Test_my

When I compile the above I get:

$ ifort two_types.f90

two_types.f90(39): error #6355: This binary operation is invalid for this data type.   [IVAR]
    is_equal = (x%j == y%j) .AND. (x%iVar == y%iVar)
-------------------------------------^
two_types.f90(39): error #6355: This binary operation is invalid for this data type.   [IVAR]
    is_equal = (x%j == y%j) .AND. (x%iVar == y%iVar)
-----------------------------------------------^
two_types.f90(58): error #6355: This binary operation is invalid for this data type.   [X]
    not_equal = .NOT. (x == y)
-----------------------^
two_types.f90(58): error #6355: This binary operation is invalid for this data type.   [Y]
    not_equal = .NOT. (x == y)
----------------------------^
two_types.f90(70): error #6355: This binary operation is invalid for this data type.   [IVAR]
    IF ( x%iVar /= y%iVar ) THEN
-----------^
two_types.f90(70): error #6355: This binary operation is invalid for this data type.   [IVAR]
    IF ( x%iVar /= y%iVar ) THEN
---------------------^
compilation aborted for two_types.f90 (code 1)

When I comment out the PRIVATE statement in question the test code compiles and runs fine:

$ diff two_types.f90 two_types_commented.f90
--- two_types.f90	2016-01-25 13:19:42.382898000 +0000
+++ two_types_commented.f90	2016-01-25 13:19:31.705164000 +0000
@@ -7,7 +7,7 @@
   TYPE, PRIVATE :: iVar_type
     INTEGER :: i = 0
   CONTAINS
-    PRIVATE  ! *** This is the statement in question ***
+!    PRIVATE  ! *** This is the statement in question ***
     PROCEDURE :: iVar_Equal
     PROCEDURE :: iVar_NotEqual
     PROCEDURE :: iVar_Compare

$ ifort two_types_commented.f90
$ ./a.out
 objects are equal

So, while I have a solution to the problem in my production code, should the ifort compiler toss an error due to this extra PRIVATE statement?

Note that the test case compiles and runs using gofrtran 4.9.x

Thanks for any info.

cheers,

paulv

The source file below produces upon compilation with ifort 16.0.0 20150815 on two slightly different parallel sandy bridge systems with

ifort -r8  -O2  -c compilererror.f90

catastrophic error: **Internal compiler error: segmentation violation signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report.  Note: File and line given may not be explicit cause of this error.
compilation aborted for compilererror.f90 (code 1)

The compilation completes without errors for -O1, without -r8 or for version 15.0.2, and maybe lower versions, too.

compilererror.f90:

module b

  implicit none
  integer :: e

contains

  subroutine a(c,d)
    implicit none
    integer :: i  
    real, dimension(-e:) :: c
    real, dimension(*) :: d

    do i=1,9
       d(i)=-c(i-1)
    enddo

end subroutine a

end module b

This is the most simple version of the error producing code I could find.
Is there anything wrong with the piece of code? What could be the reason for the (optimizer?) error?

Thanks in advance!

K.H

All,

Been working for a while having 'fun' trying to port the General Polygon Clipper (GPC) Library from C to Fortran but decided it may be easier to just to call the 2-3 GPC 'C' routines I need from my Fortran code. All the polygon info is contained in 'typedef struct's in the C code which are as follows:

*********************************************************************************

typedef enum                        /* Set operation type                */
{
  GPC_DIFF,                         /* Difference                        */
  GPC_INT,                          /* Intersection                      */
  GPC_XOR,                          /* Exclusive or                      */
  GPC_UNION                         /* Union                             */
} gpc_op;

typedef struct                      /* Polygon vertex structure          */
{
  double              x;            /* Vertex x component                */
  double              y;            /* vertex y component                */
} gpc_vertex;

typedef struct                      /* Vertex list structure             */
{
  int                 num_vertices; /* Number of vertices in list        */
  gpc_vertex         *vertex;       /* Vertex array pointer              */
} gpc_vertex_list;

typedef struct                      /* Polygon set structure             */
{
  int                 num_contours; /* Number of contours in polygon     */
  int                *hole;         /* Hole / external contour flags     */
  gpc_vertex_list    *contour;      /* Contour array pointer             */
} gpc_polygon;

*********************************************************************************

The prototypes of the 3 GPC routines I need to communicate with are:

void gpc_add_contour         (gpc_polygon     *polygon,
                              gpc_vertex_list *contour,
                              int              hole);

void gpc_polygon_clip        (gpc_op           set_operation,
                              gpc_polygon     *subject_polygon,
                              gpc_polygon     *clip_polygon,
                              gpc_polygon     *result_polygon);

void gpc_free_tristrip       (gpc_tristrip    *tristrip);

On the Fortran side, my equivalent Derived Types are:

  TYPE :: gpc_op                                    !   /* Set operation type                */
    INTEGER :: GPC_DIFF=0                            !    /* Difference                        */
    INTEGER :: GPC_INT=1                            !    /* Intersection                      */
    INTEGER :: GPC_XOR=2    !***not used            !    /* Exclusive or                      */
    INTEGER :: GPC_UNION=3                            !    /* Union                             */
  END TYPE

  TYPE :: GPC_VERTEX                    !    /* Polygon vertex structure          */
    REAL(8) :: x                                    !    /* Vertex x component                */
    REAL(8) :: y                                    !    /* vertex y component                */
  END TYPE

  TYPE :: GPC_VERTEX_LIST                !    /* Vertex list structure             */
    INTEGER :: num_vertices                            !    /* Number of vertices in list        */
    TYPE (GPC_VERTEX),ALLOCATABLE :: vertex(:)        !    /* Vertex array pointer              */
  END TYPE

  TYPE :: GPC_POLYGON                         !    /* Polygon set structure             */
    INTEGER :: num_contours                            !    /* Number of contours in polygon     */
    INTEGER :: hole            ! added                    !    /* Hole / external contour flags     */
    INTEGER,ALLOCATABLE :: holea(:)       ! changed        !    /* Hole / external contour flags     */
    TYPE (GPC_VERTEX_LIST),ALLOCATABLE :: contour(:)    !    /* Contour array pointer             */
  END TYPE

**********************************************************************************************

Now, I have ZERO experience (and have found no references or examples) as to how the INTERFACE would be constructed to exchange data between Fortran & C structures. For example...the Fortran subroutine cgr_polydiff calls gpc_polygon_clip in the following way:

SUBROUTINE cgr_polydiff(npin0,xin0,yin0,npin1,xin1,yin1,maxnpo,npo,xo,yo,iret)
! --------------------------------------------------
!/************************************************************************
! * cgr_polydiff                             *
! *                                    *
! * This function computes the difference of two polygons using the      *
! * difference clipping option in the GPC (General Polygon Clipper)      *
! * library.  The area that is in polygon 0 but not in polygon 1 is     *
! * returned.                                *
! *                                    *

! * Input parameters:                            *
! * *npin0            int     Number of points in polygon 0               *
! * *xin0             float   X coordinates of polygon 0                  *
! * *yin0             float   Y coordinates of polygon 0                  *
! * *npin1            int     Number of points in polygon 1               *
! * *xin1             float   X coordinates of polygon 1                  *
! * *yin1             float   Y coordinates of polygon 1                  *
! * *maxnpo           int     Maximum number of output points        *
! *                                    *
! * Output parameters:                            *
! * *npo              int     Number of points in output polygon          *
! * *xo               float   X coordinates of output polygon             *
! * *yo               float   Y coordinates of output polygon             *
! * *iret             int     Return code                    *
! *                    =  1 - no area in 0 that isn't in 1        *
! *                 = -1 - insufficient maxnpo            *
! *                 = -2 - polygons have insufficient # of pts    *
! *                                    *
! **                                    *

USE GPC

! - - - arg types - - -
  INTEGER :: npin0,npin1,iret                                                
  INTEGER :: maxnpo,npo                                                      
  REAL(4) :: xin0,yin0                                                     
  REAL(4) :: xin1,yin1                                                     
  REAL(4) :: xo,yo                                                       
! - - - local declarations - - -
  INTEGER :: ii,hole,ier
  TYPE(GPC_POLYGON) :: gpc_poly_0
  TYPE(GPC_POLYGON) :: gpc_poly_1
  TYPE(GPC_POLYGON) :: gpc_diff_poly
  TYPE(GPC_VERTEX_LIST) :: verts
! - - - begin - - -

< - snip - >

  CALL gpc_polygon_clip( GPC_DIFF, gpc_poly_0, gpc_poly_1, gpc_diff_poly )

*************************************************************************************

Using Intel® Parallel Studio XE 2015 Composer Edition for Fortran Windows, how would the INTERFACE be constructed to handle this example?

Thanks in advance,

Jeff

Dear All:

I am trying to understand using pointer locally in fortran subroutine. That's why i wrote a simple code, where subroutine is called several times, to find out list of odd numbers from a given rang. Basically i used a linked list to save odd numbers and then copied linked list to output of subroutine(I know there are a lot of   ways to do this job but that is not concern right now, rather i would like to understand memory leak issue). My code contains some memory leak issues. Would somebody help to figure out the problem?.

program pointer_test
    implicit none
    integer,allocatable::odd_list(:)
    integer::i
    call find_odd(odd_list,1,23)
    print*,'Odd list after first call',odd_list
    call find_odd(odd_list,5,17)
    print*,'Odd list after second call',odd_list
    call find_odd(odd_list,6,19)
    print*,'Odd list after third call',odd_list
    contains

    subroutine find_odd(odd_list,low_bound,high_bound)
        implicit none
        integer,allocatable,intent(out)::odd_list(:)
        integer,intent(in)::low_bound,high_bound
        integer::count,index,i
        type node
            integer:: info
            type(node),pointer::next
        end type node

        type(node),pointer::head,current,temp

        if (associated(head))nullify(head)
        if (associated(current))nullify(current)
        if (associated(temp))nullify(temp)

        do i=low_bound,high_bound
            if (mod(i,2) .ne. 0) then
                if (.not. associated(head))then
                    allocate(head)
                    head%info=i
                    nullify(head%next)
                    current=>head
                else
                    allocate(current%next)
                    current%next%info=i
                    nullify(current%next%next)
                    current=>current%next
                end if
            end if
        end do

        temp=>head
        count=0
        do while(associated(temp))
            count=count+1
            temp=>temp%next
        end do

        allocate(odd_list(count))

        nullify(temp)
        temp=>head
        index=0
        do while(associated(temp))
            index=index+1
            odd_list(index)=temp%info
            temp=>temp%next
        end do


    end
end

Regards

Masrul  
 

The program below shows a different behavior for SIZE and ALLOCATED across coarray images. Naively, I would assume that both work (SIZE does, ALLOCATED does not) if the only thing they do is read the array descriptor data. Is there an explanation for this?

PROGRAM MAIN
IMPLICIT NONE
TYPE TT
    INTEGER,ALLOCATABLE :: VALUES(:)
END TYPE TT
TYPE(TT) :: T[*]
INTEGER :: I
SYNC ALL
IF (THIS_IMAGE()>1) THEN
    ALLOCATE(T%VALUES(THIS_IMAGE()))
END IF
SYNC ALL
IF (THIS_IMAGE()==1) THEN
    DO I=2,NUM_IMAGES()
        WRITE(*,*) ALLOCATED(T[I]%VALUES)
        WRITE(*,*) SIZE(T[I]%VALUES)
    END DO
END IF
END PROGRAM MAIN

Hello,

I am working on Intel Visual Fortran 11.1 and have a question on declaring an array in a subroutine by defining the size of the array using an argument. The argument can vary each time the subroutine is called, and the compiler does not provide an error, nor a warning.

program main
call suppre(5)
call suppre(6)
stop
end

subroutine suppre(ivar)
integer ivar
real, dimension(ivar) :: array

end subroutine

My question: What are the drawbacks of this practice?

The following code sample with generic assignment(=) interfaces compiles fine under Version 15.0.5.280. I just installed Version 16 and it produces an error.

module test
implicit none
private

    type, public :: ref_t
        private
        integer :: idum = 0
    contains
        generic :: assignment(=) => get_new
        generic :: assignment(=) => acquire
        procedure, private :: get_new
        procedure, private :: acquire
    end type

contains

    subroutine get_new(my,ptr)
        class(ref_t), intent(out) :: my
        class(*), pointer, intent(in) :: ptr
        print *, "get_new"
        my%idum = 1
    end subroutine

    subroutine acquire(my,ref)
        class(ref_t), intent(out) :: my
        class(ref_t), intent(in)  :: ref
        print *, "acquire"
        my%idum = ref%idum+1
    end subroutine

end module

program main
call run
contains
subroutine run
use test

    type(ref_t) a,b
    class(*), pointer :: p

    a = p
    b = a

end subroutine
end program

With Version 15, I can compile and get the following output:

$ ./GenericAmbiguity.exe
 get_new
 acquire

But with Version 16, I get the following error message:

$ ifort GenericAmbiguity.f90
Intel(R) Visual Fortran Compiler for applications running on IA-32, Version 16.0 Build 20151021
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

GenericAmbiguity.f90(24): error #8437: The type/rank signature for the arguments of this specific subroutine matches another specific subroutine that shares the same ASSIGNMENT generic binding.   [ACQUIRE]
        subroutine acquire(my,ref)
-------------------^
compilation aborted for GenericAmbiguity.f90 (code 1)

Since `acquire` has a more specific interface than `get_new`, it seems that there should be no ambiguity (unless, of course, the actual argument is of type `class(ref_t),pointer`).

So why the change from V15 to V16?

Hello,

I installed the Intel Fortran Compiler and Microsoft Visual Studio, both in their latest version. I am having an issue with building my test program. The builder runs and says it has been successful but no .exe file was created and I am unable to run the program (I get a message saying that no .exe file can be found) 

I feel like there is something simple I am not doing. 

Any advice?

Thanks,

Erez

I am currently using VS2010/IVF XE2013 SP1 together with Windows 8. Can anyone tell me if my programming environment will work with Windows 10 ?

I am trying to use the 2016 compiler in VS 2010. Everything looks fine, it knows about the Fortran, and I can open the sample 'Hello world' project. However, when I try to compile the source file with right-click/compile I get a 'The operation could not be completed' error message. Further, if I right-click on any item e.g. the source file in the Solution Explorer tree end select 'Properties',  I get 'Class not registered. Looking for object with CLSID: {F0F74B93-6F3C-4212-897A-DF6A62B91A8AJ}.

I have repaired and modified the compiler installation several times, with no effect. I have tried to unregister and register the dlls following 'https://software.intel.com/en-us/articles/troubleshooting-fortran-integr...'. All four unregister, but VFProj.dll always fails to register again, with, I believe, an 'access denied' error. In regedit the permissions for HKEY_CLASSES_ROOT are 'full' for system and administrators, as also for CLSID.

In a command prompt I can compile, link and execute the 'Hello world' example, so it must be linked to the VS 2010 integration somehow..

The machine is running Windows 7, and I have a successful integration of ComposerXE-2011 in VS2008.

Does anyone have any ideas on how to solve this problem?

Thanks,

John

I have two DLLs that I'm interested in.  Let's call them Main.dll and Plugin.dll, both written in Fortran.

Plugin.dll needs to access various functions and COMMONs from Main.dll.  Ok, so I added a few

      !DIR$ ATTRIBUTES DLLIMPORT :: /WHATEVER/

kind of statements, and created a module definition file to go along with Main.dll.  The user of Main.dll and Plugin.dll loads everything into memory, and life is good.

Now for the problem.  The user of Main.dll wants to run two instances of Main.dll.  So, in order to give each instance of Main.dll its own COMMON blocks, I copy Main.dll into C:\Windows\Temp\{runtime generated GUID}\{runtime generated GUID}.dll and C:\Windows\Temp\{another runtime generated GUID}\{another runtime generated GUID}.dll.  But now, I get a MessageBox stating "The program can't start because Main.dll is missing from your computer.  Try reinstalling the program to fix this problem".

So ... how do I tell Plugin.dll that, nevermind, instead of Main.dll you should now link up with {runtime generated GUID}.dll?

As shown below, compiling this trivial program with ifort 16.0.1 results in a binary that dumps core if its stdout is redirected to a file. Compiling the same code with ifort 15.0 results in no such problem.

watrok@amrndhl765:$ cat ok.f90
PRINT *,'ok'
END
watrok@amrndhl765:$ module purge
watrok@amrndhl765:$ module load intel/16.0.1
watrok@amrndhl765:$ ifort -v
ifort version 16.0.1
watrok@amrndhl765:$ ifort -o ok-16.0.1 ok.f90
watrok@amrndhl765:$ ls
ok-16.0.1 ok.f90
watrok@amrndhl765:$ ./ok-16.0.1
ok
watrok@amrndhl765:$ ./ok-16.0.1 > ok.out
*** buffer overflow detected ***: ./ok-16.0.1 terminated
======= Backtrace: =========
/lib64/libc.so.6(__fortify_fail+0x37)[0x3808902507]
/lib64/libc.so.6[0x38089003f0]
/lib64/libc.so.6[0x38088ff849]
/lib64/libc.so.6(_IO_default_xsputn+0xc9)[0x38088748b9]
/lib64/libc.so.6(_IO_vfprintf+0x11d8)[0x3808845428]
/lib64/libc.so.6(__vsprintf_chk+0x9d)[0x38088ff8ed]
/lib64/libc.so.6(__sprintf_chk+0x7f)[0x38088ff82f]
./ok-16.0.1[0x445add]
./ok-16.0.1[0x4473e9]
./ok-16.0.1[0x4340ad]
./ok-16.0.1[0x4097fe]
./ok-16.0.1[0x402e9f]
./ok-16.0.1[0x402e1e]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x380881ecdd]
./ok-16.0.1[0x402d29]
======= Memory map: ========
00400000-004b1000 r-xp 00000000 00:38 5515555723 /hpc/grid/scratchtest/watrok/f90/ok-16.0.1
006b0000-006b4000 rw-p 000b0000 00:38 5515555723 /hpc/grid/scratchtest/watrok/f90/ok-16.0.1
006b4000-006d2000 rw-p 00000000 00:00 0
01675000-01696000 rw-p 00000000 00:00 0 [heap]
3567c00000-3567c16000 r-xp 00000000 fd:00 529492 /lib64/libgcc_s-4.4.7-20120601.so.1
3567c16000-3567e15000 ---p 00016000 fd:00 529492 /lib64/libgcc_s-4.4.7-20120601.so.1
3567e15000-3567e16000 rw-p 00015000 fd:00 529492 /lib64/libgcc_s-4.4.7-20120601.so.1
3808000000-3808020000 r-xp 00000000 fd:00 555367 /lib64/ld-2.12.so
380821f000-3808220000 r--p 0001f000 fd:00 555367 /lib64/ld-2.12.so
3808220000-3808221000 rw-p 00020000 fd:00 555367 /lib64/ld-2.12.so
3808221000-3808222000 rw-p 00000000 00:00 0
3808400000-3808402000 r-xp 00000000 fd:00 555377 /lib64/libdl-2.12.so
3808402000-3808602000 ---p 00002000 fd:00 555377 /lib64/libdl-2.12.so
3808602000-3808603000 r--p 00002000 fd:00 555377 /lib64/libdl-2.12.so
3808603000-3808604000 rw-p 00003000 fd:00 555377 /lib64/libdl-2.12.so
3808800000-380898a000 r-xp 00000000 fd:00 555368 /lib64/libc-2.12.so
380898a000-3808b89000 ---p 0018a000 fd:00 555368 /lib64/libc-2.12.so
3808b89000-3808b8d000 r--p 00189000 fd:00 555368 /lib64/libc-2.12.so
3808b8d000-3808b8e000 rw-p 0018d000 fd:00 555368 /lib64/libc-2.12.so
3808b8e000-3808b93000 rw-p 00000000 00:00 0
3808c00000-3808c17000 r-xp 00000000 fd:00 534292 /lib64/libpthread-2.12.so
3808c17000-3808e17000 ---p 00017000 fd:00 534292 /lib64/libpthread-2.12.so
3808e17000-3808e18000 r--p 00017000 fd:00 534292 /lib64/libpthread-2.12.so
3808e18000-3808e19000 rw-p 00018000 fd:00 534292 /lib64/libpthread-2.12.so
3808e19000-3808e1d000 rw-p 00000000 00:00 0
3809000000-3809083000 r-xp 00000000 fd:00 555370 /lib64/libm-2.12.so
3809083000-3809282000 ---p 00083000 fd:00 555370 /lib64/libm-2.12.so
3809282000-3809283000 r--p 00082000 fd:00 555370 /lib64/libm-2.12.so
3809283000-3809284000 rw-p 00083000 fd:00 555370 /lib64/libm-2.12.so
7f7f990fc000-7f7f99101000 rw-p 00000000 00:00 0
7f7f99124000-7f7f99126000 rw-p 00000000 00:00 0
7fff5fc7f000-7fff5fc95000 rw-p 00000000 00:00 0 [stack]
7fff5fcd4000-7fff5fcd5000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
forrtl: error (76): Abort trap signal
Image PC Routine Line Source
ok-16.0.1 0000000000477435 Unknown Unknown Unknown
ok-16.0.1 00000000004751F7 Unknown Unknown Unknown
ok-16.0.1 0000000000444AE4 Unknown Unknown Unknown
ok-16.0.1 00000000004448F6 Unknown Unknown Unknown
ok-16.0.1 00000000004259F6 Unknown Unknown Unknown
ok-16.0.1 00000000004037D8 Unknown Unknown Unknown
libpthread.so.0 0000003808C0F500 Unknown Unknown Unknown
libc.so.6 00000038088328A5 Unknown Unknown Unknown
libc.so.6 0000003808834085 Unknown Unknown Unknown
libc.so.6 00000038088707B7 Unknown Unknown Unknown
libc.so.6 0000003808902507 Unknown Unknown Unknown
libc.so.6 00000038089003F0 Unknown Unknown Unknown
libc.so.6 00000038088FF849 Unknown Unknown Unknown
libc.so.6 00000038088748B9 Unknown Unknown Unknown
libc.so.6 0000003808845428 Unknown Unknown Unknown
libc.so.6 00000038088FF8ED Unknown Unknown Unknown
libc.so.6 00000038088FF82F Unknown Unknown Unknown
ok-16.0.1 0000000000445ADD Unknown Unknown Unknown
ok-16.0.1 00000000004473E9 Unknown Unknown Unknown
ok-16.0.1 00000000004340AD Unknown Unknown Unknown
ok-16.0.1 00000000004097FE Unknown Unknown Unknown
ok-16.0.1 0000000000402E9F Unknown Unknown Unknown
ok-16.0.1 0000000000402E1E Unknown Unknown Unknown
libc.so.6 000000380881ECDD Unknown Unknown Unknown
ok-16.0.1 0000000000402D29 Unknown Unknown Unknown
Aborted (core dumped)
watrok@amrndhl765:$ ls
ok-16.0.1 ok.f90 ok.out
watrok@amrndhl765:$ module purge
watrok@amrndhl765:$ module load intel/15.0
watrok@amrndhl765:$ ifort -v
ifort version 15.0.0
watrok@amrndhl765:$ ifort -o ok-15.0 ok.f90
watrok@amrndhl765:$ ./ok-15.0
ok
watrok@amrndhl765:$ ./ok-15.0 > ok.out
watrok@amrndhl765:$ cat ok.out
ok
watrok@amrndhl765:$ ls -l
total 2598
-rwxr-xr-x 1 watrok root 724005 Jan 27 15:53 ok-15.0
-rwxr-xr-x 1 watrok root 773645 Jan 27 15:52 ok-16.0.1
-rw-r--r-- 1 watrok amer 17 Jan 27 15:51 ok.f90
-rw-r--r-- 1 watrok root 4 Jan 27 15:53 ok.out

For various reasons, I need to use the compiler at command line to compile a project that I had previously been compiling successfully in Visual Studio 2012. 

The Solution properties pages show several different command lines, one for "Fortran," one for "Linker," one for "Resources," and one for MIDL. Can I combine these somehow as as argument to the ifort command so that one call to ifort builds the entire solution (equivalent to "Rebuild Solution" in Visual Studio)? If so, how? Just concatenate them, or something else?

Also, the documentation says that the source files need to be put in the correct order so that dependencies are resolved correctly. If I Rebuild Solution in Visual Studio, does the order of compilation as shown in the Output Window correspond to the appropriate ordering of the files on the command line?

Thanks for any insight.

Using a program like this:

      program main
      call crash()
      end program
      
      
      subroutine crash()
      use kernel32
      integer(HANDLE) hFile
      integer(DWORD) iSize
      integer(DWORD) iSizeRW
      integer iTotalSize,iTotalSizeRW
      integer(BOOL) iResult
      
      iTotalSize=78439242
      hFile=0
      iSize = sizeof(iTotalSize)
      iResult = 1
      iSizeRW = iSize
      iResult=WriteFile(hFile,loc(iTotalSize),iSize,loc(iSizeRW),NULL)
      end subroutine
      

With /integer_size:64 (and only on the Win32 platform), and using ifort 2015 Update 4, at the end of subroutine crash(), I get ebp-esp = 4, and the error message:

Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call.  This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.

So ... what did I mess up now?