In the manual I found:

EXTERNAL FACET
CALL BAR(FACET)
SUBROUTINE BAR(F)
EXTERNAL F
CALL F(2)

I would like something as:

SUBROUTINE BAR(F,t,y)
EXTERNAL, DIMENSION(1:2) :: F
EXTERNAL fun
fun = F(1)
CALL fun(t,y)
fun = F(2)
CALL fun(t,y)

and

f(1) = myode
f(2) = myresult

SUBROUTINE myode(t,y)
! do something
END

SUBROUTINE myresult(t,y)
! do something
END

Do you think it is possibile?

I found these two TYPE declarations are not welcome:

1. EXTERNAL in type is not accept

TYPE myvar
EXTERNAL :: fun
END TYPE

2. this trick is not allowed

TYPE myvec
INTEGER :: n
REAL*8, DIMENSION(1:n) :: x
END TYPE

Some workarounds is possible?

I am in the process of converting from Compaq Visual Fortran to Intel Visual Fortran. 

I am trying to run simple "hello_world" program.

My program complies just fine with:   "Ifort /c hello_world.f90"

However, when I link with "Ifort /exe:runmodel.exe hello_world.obj"

I get the following error messages

-out:runmodel.exe
-subsystem:console
-incremental:no
Hello_world.obj
Hello_world.obj : error LNK2019: unresolved external symbol ___intel_new_feature_proc_init referenced in function _MAIN__
Hello_world.obj : error LNK2019: unresolved external symbol _for_set_reentrancy referenced in function _MAIN__
Hello_world.obj : error LNK2019: unresolved external symbol _for_write_seq_fmt referenced in function _MAIN__
LINK : error LNK2001: unresolved external symbol _mainCRTStartup
runmodel.exe : fatal error LNK1120: 4 unresolved externals

So, what am I doing wrong?

I'm compiling a fortran DLL project. I have two subroutines in the same .f file. The first one shown below calls the second one, but I'm getting unresolved external symbol. The problem must be how I'm exporting them so they can be called from Excel VBA.

I have iface set to Default for this project.
The unresolved error goes away if I remove the !DEC statement from SUBB, but I need it.
All the argument variables are numeric except for the one called rtn.

What the heck am I doing wrong?!@#$

subroutine SUBA(nx, alfa_r, alfa_i, z_r, z_i, nev, irvec,
& Lindex_k, Lvalue_k, index_k, value_k, ne_k,
& Lindex_m, Lvalue_m, index_m, value_m, ne_m,
& W, ierr, rtn)
!DEC$ ATTRIBUTES DLLEXPORT, STDCALL, REFERENCE, ALIAS:"SUBA" :: SUBA
character(10) :: rtn
!DEC$ ATTRIBUTES REFERENCE :: rtn

subroutine SUBB(nx, Lindex, Lvalue, index, value, ne_, ierr)
!DEC$ ATTRIBUTES DLLEXPORT, STDCALL, REFERENCE, ALIAS:"SUBB" :: SUBB

This discussion is going to be generic until I can create a suitable small test case.  I am just hoping somebody has seen this problem before and can point me in the right direction.

I am attempting to create a TYPE and a TYPE which extends the original.  I then wish to use the second (child class) in many places around my fixed-form Fortran code.  I have been getting the warning message 

warning #8499: The procedure has a dummy argument that is polymorphic. Required explicit interface is missing from original source.

Then comes the internal compiler error.  If I put an explicit interface in the code, the warning disappears but the ICE remains.

I know these statements are general, but my current "small" example has a PROGRAM, two SUBROUTINEs and 16 modules.  Once I start paring it down, I have not had much luck reproducing the ICE.

Any help would be appreciated.

Intel(R) Visual Fortran Compiler XE 15.0.4.221 [IA-32]

     The following problem, involving "Multithreaded" vs. "Multithread Dll" Runtime Libraries, is not critical to anything I'm doing, but my curiosity is aroused.
     The program is written in .f90 code developed and compiled with MSVS Professional 2013 with Intel Parallel Studio XE 2015 Update 4 Composer Edition For Fortran Windows*. It "USE's":lapack95, OMP_LIB and two homemade MODULE's.

     The Fortran Project Properties, Command Line reads:
/nologo /O3 /QxHost /Qparallel /heap-arrays0 /Qopt-matmul/Qopenmp /real_size:64 /Qfp-speculation=safe/module:"x64\Release\\" /object:"x64Release\\"/Fd"x64\Release\vc120.pdb" /check:none /libs:static/threads /Qmkl:parallel /c

     The program compiles and runs without errors or warnings on my PC#1, with an i7-860 CPU, running Windows 7 Ultimate SP1.

     If, however, I copy the entire project into my PC#2, with an i7-4770 CPU, running Windows 7 Professional SP1, compilation fails, giving the errors:

Error 2  error LNK2001: unresolved external symbol__intel_lib_iob_func libifcoremt.lib(for_diags_intel.obj)
Error 3  error LNK2001: unresolved external symbol__intel_lib_iob_func libifcoremt.lib(for_nt_open_proc.obj) 
Error 1  error LNK2019: unresolved external symbol__intel_lib_iob_func referenced in function for_pause libifcoremt.lib(for_pause.obj) 
Error 4  fatal error LNK1120: 1 unresolved externals x64\Release\SCF-MO-GTO.exe

If I change the Fortran Project Properties, Fortran:Libraries:Runtime Libraries from "Multithreaded" (ie Static) to "Multithread DLL" (ie Dynamic), the program compiles and runs on both PC#1 and PC#2 without errors. So long as I run the program in the VS2013 IDE ("Start Without Debugging") I do not need to provide access to any .dll's. If I run 'outside' of the IDE, I must make the following five dll's available in the folder with the program .exe:

mkl_rt.dll; mkl_core.dll; mkl_def.dll; mkl_intel_thread.dll; mkl_mc3.dll

My question, of course, is why does the program, with "Multithreaded", compiles and runs o.k. on PC#1, but not on PC#2. VS2013 and Intel Parallel Studio 2015 were installed on both machines with the same installation packages and the same options, SFAIK.

Don

I want to run a fortran code in debug mode in visual studio.  the code reads input from stdin (unif 5).  I would like it to read from an input file.  Can you tell me how to assign my input file to stdin?

Hello,

I am attempting to create a simple windowing application in Fortran using Visual Studio.  I have experience with C and BASIC, but I am completely new to Fortran.  In order to create my application, I have started off by attempting to reverse engineer the sample SDI code, and so far it has done a great deal to familiarize me with the nuances of this language.

However, I am still having trouble understanding what some of the code exactly does, and I cannot seem to find references that cover Fortran windowing applications.  I was wondering if anyone could link me with helpful references that I could use to look up these things.

Thanks,

JS

This topic must have been beaten to death, but the issue I've encountered seems very odd.

Here is the C code:

void test_array(int *, int *, double **); // To test accessing a Fortran 2D array.

void test_get_array()

{

    int i;

    int narr1, narr2;

    double *farr;

    test_array(&narr1, &narr2, &farr);

    for (i=0;i<narr1*narr2; i++)

        printf("%d %f\n",i,farr[i]);

}

and the Fortran:

subroutine test_array(narr1, narr2, cptr) bind(C)
!DEC$ ATTRIBUTES DLLEXPORT :: test_array
use, intrinsic :: iso_c_binding
integer(c_int) :: narr1, narr2
TYPE (C_PTR)    :: cptr
real(c_double), allocatable, target :: a(:,:)
integer :: i1, i2
integer :: n1=4, n2=3

allocate(a(n1,n2))
do i1 = 1,n1
    do i2 = 1,n2
        a(i1,i2) = i1 + 10*i2
    enddo
enddo

narr1 = n1
narr2 = n2
cptr = c_loc(a)
write(*,'(4f6.0)') a

end subroutine

This is the output:

11. 12. 13. 14.

21. 22. 23. 24.

31. 32. 33. 34.

0 0.000000

1 12.000000

2 13.000000

3 14.000000

4 21.000000

5 22.000000

6 23.000000

7 24.000000

8 31.000000

9 32.000000

10 33.000000

11 34.000000

What has happened to the first array entry?

Hang on!  I just remembered seeing something about SAVE.  When I add that to the declaration of a(:) I get the first entry correctly.  I'm guessing that not SAVEing immediately clobbers the start of the array somehow on subroutine return.  I decided to leave the post here because the phenomenon is interesting and I'd like to see comments on it.

Thanks

Gib

This will not be an easy question to handle for anyone as it involves a lot of variables. We shifted on to Windows 8.1 and started observing this issue.

OS: Windows 8.1 Enterprise

VS: Visual Studio 2008 SP1

VF: Intel(R) Visual Fortran Compiler Integration for Microsoft Visual Studio* 2008, 11.1.3469.2008

When you have variables added to the watch window and are stepping through the code (F10), Visual Studio can take up to 3 seconds going through each line when going through Fortran projects. The mouse cursor would change to waiting (small circle) when the program is waiting to move to the next line. This depends on the number of variables that are being added to the Watch window i.e. a couple of variable then wait time may be less than 0.1 second, up to say 50 variables wait time > 3 seconds each line. If you get rid of all the variables in the watch window, debugging would run smoothly without any delays.

We started observing this issue with Windows 8.1. Windows 7 did not have this issue keeping all the other installations the same. I tried to reproduce the same issue on a VM, but could not and the debugging ran smoothly for the same project regardless of the number of variable added to the watch window. May be it is because of some Hotfix.

This is really frustating to us, and any help from your guys would be hugely appreciated.

Thank you.

Greetings,

I'm writing an ABAQUS FILM user subroutine.  The subroutine uses many supporting modules to get the job done, and works well with a dummy driver.  I'm most experienced writing stand-alone code, i..e., main + subs.  How do I compile in Visual Studio to create a single *.obj with only the sub and supporting modules to present to ABAQUS?  Excluding the main dummy program from the build generates an error regarding the missing external routine.  Failing that can I manually concatenate the many obj files VS makes into a single file, or must I concatenate the modules' source code to generate a single obj file?

Also: How can I get Visual Studio to create a makefile (NMAKE?) from the IDE so other users can recompile from the command line?  The HELP leaves me confused.  Creating a Makefile from scratch is always a painful exercise for me, and presenting the many supporting modules to the linker begs for a script.

Thanks,

John W

The compiler error with the following code appears to be incorrect:

module m

   implicit none

   private

   type, public :: t
      private
      integer, pointer :: m_i
   contains
      private
      procedure, pass(this), public :: iptr => getptr
      procedure, pass(this), public :: setptr
   end type t


contains

   subroutine setptr( this, iptr )

      !.. Argument list
      class(t), intent(inout)         :: this
      integer, pointer, intent(inout) :: iptr

      this%m_i => iptr

      return

   end subroutine setptr

   function getptr( this ) result( iptr )

      !.. Argument list
      class(t), intent(in) :: this
      !.. Function result
      integer, pointer :: iptr

      iptr => this%m_i

      return

   end function getptr

end module m

program p

   use m, only : t

   integer, pointer :: i
   type(t) :: foo

   print *, " Is i associated with foo%iptr? ", associated( i, foo%iptr() )

   stop

end program p

Compiling with Intel(R) Visual Fortran Compiler XE 15.0.4.221 [Intel(R) 64]...
p.f90
C:\..\p.f90(8): error #6808: The TARGET argument must have the POINTER or TARGET attribute.
[ASSOCIATED]
compilation aborted for C:\..\p.f90 (code 1)

When I Debug the attached code with VS2010 and IVF XE2013 (and 2011 on colleagues machine) on entering the subroutine SCALC, after a break point has been placed at line 448, causes Visual Studio (VS) to stop working (crash).  Debugging VS in another instance of VS states that a buffer overrun in devenv.exe has corrupted the programs internal state.  With no break point, or in Release mode, the program executes and terminates normally.

This code is from a large legacy Fortran program (650+ routines) and I have distilled down to just a few lines to demo issue.  The original code is characterised by very large argument lists being passed between subroutines.  However, it has been compiled with IVF for many years without issue.  Although I agree that the code style is legacy and ugly I do not think it breaks any basic rules.  I have checked that the argument list between the calling program and SCALC is consistent.  I tried varying the size of argument FEF (hardcoded to 100) and found that the code debugs normally if set to 99.  However, it could also be increased if the argument position was changed.  i.e. This seems like a real flaky memory issue but I cannot see anything wrong in the code and so I am starting to wonder if it is from the development environment.

I attach the VS project and source file: crash.f - please see if you can verify.  i.e.  (1) Open project with VS, (2) Insert a break point at line 448, and see if you can (3) Debug to this break point without crash.  If your test also crashes I would be grateful if you have any suggestions.  Jon

Dear DZ

I have just updatet my fortran compiler under WS(Professional 2013 - update 4) with Intel® Parallel Studio XE Composer Edition for Fortran Windows*.

Unfortunately, my code is no longer able to maintain the same calculation accuracy (machine eps = 1.2D-19) using the ifport modules (GETCONTROLFPQQ and SETCONTROLFPQQ), se the below code, which now creates the standard machine eps = 2.2D-16.

Are there any compiler settings to fix that problem, any guidance???

Thanks in advance!

Regards

Axel Ohrt Johansen

subroutine fpprecis()

use ifport

use dflib

integer(2) control, holdcontrol, newcontrol

real(8) A,EPSMAC

CALL GETCONTROLFPQQ(control)

! Clear any existing precision flags.

holdcontrol = IAND(control, NOT(FPCW$MCW_PC))

newcontrol = IOR(holdcontrol, FPCW$64)

! Set precision to 64 bits.

CALL SETCONTROLFPQQ(newcontrol)

! Test - machine eps:

EPSMAC=1.0D0

100 EPSMAC=EPSMAC/2.0D0

A=EPSMAC+1.0D0

IF(A.NE.1.0D0) GO TO 100

EPSMAC=2.0D0*EPSMAC

Write(6,*) EPSMAC

end subroutine fpprecis

Duplicate.

Hi,

I need to install and build PETSc with Intel MPI and compilers. It has so far been unsuccessful.

It seems that I need to know which mpi libraries to link to

The compiling and building is done in cygwin64.

The commands are:

export PETSC_DIR=`pwd`

export PETSC_ARCH=petsc-3.6.0_win64_impi_vs2012_debug

I then tried the 4 options below but they all failed. Does anyone manage to get it working?

1. ./config/configure.py --with-cc='win32fe mpiicc.bat' --with-fc='win32fe mpiifort.bat' --with-cxx='win32fe mpiicpc.bat' --with-blas-lapack-dir=/cygdrive/c/Program\ Files\ \(x86\)/Intel/Composer\ XE\ 2015/mkl/ --prefix=/cygdrive/c/wtay/Lib/petsc-3.6.0_win64_impi_vs2012_debug --with-debugging=1

2. ./config/configure.py --with-cc='win32fe cl' --with-fc='win32fe ifort' --with-cxx='win32fe cl' --with-mpi-include=/cygdrive/c/Program\ Files\ \(x86\)/Intel/MPI/5.0.3.048/intel64/include --with-mpi-lib="/cygdrive/c/Program Files (x86)/Intel/MPI/5.0.3.048/intel64/lib/impi.lib" --with-blas-lapack-dir=/cygdrive/c/Program\ Files\ \(x86\)/Intel/Composer\ XE\ 2015/mkl/ --prefix=/cygdrive/c/wtay/Lib/petsc-3.6.0_win64_impi_vs2012_debug --with-debugging=1

Also, how can I get intel premier support? It says not authorized. I've already registered my product (cluster edition 2015).

Thank you.

Hi,

while importing the open-source project CP2K, I came across a problem with parsing the input files. Opening the attached file d3_poly.F in Visual Studio 2015 with Intel Parallel Studio XE 2015 U4 immediately crashes the Visual Studio UI for me. Can anybody confirm this issue?

Kind regards,

Guido

Hello,

I am using Parallel Studio XE2015 to compile a program that was compiled with Visual Fortran in the past. It looks like the compiler is ignoring !DIR$ and cDEC$ compiler directives. Initially, I thought cDEC$ had been deprecated, but !DIR$ is also being ignored. Do I need a special compilation switch?  The program uses mostly fixed-form 72-column code, but it uses longer fixed-form code and freeform code in a few places, and I need the directives for this purpose.

BTW, I have enabled the pre-processor (/fpp); does it interfere with these directives?

Any suggestions?

Thanks,

Gabriel

Hi all,

Encountered a little puzzle.  Using default project settings for a console application, the following code creates a format specification statement with an internal write and then uses that format specifier in another write statement:

program WidthSpecifierError

   character(LEN=200) :: cLine
   integer(KIND=4) :: iLen, iArray(11)

   iLen = 11
   iArray(1:11) = (/1,2,3,4,5,6,7,8,9,10,11/)

   write(*,*) 'Writing integer larger than width specifier'
   write(cLine,'("(",I1,"(I2,1X))")') iLen
   write(*,*) cline
   write(*,cline) (iArray(i), i=1,iLen)
   write(*,*)
   write(*,*) 'Writing integer equal to width specifier'
   write(cLine,'("(",I2,"(I2,1X))")') iLen
   write(*,*) cline
   write(*,cline) (iArray(i), i=1,iLen)

end program WidthSpecifierError

The output is thus under default Debug and Release compilation:

 Writing integer larger than width specifier
 (*(I2,1X))

 1  2  3  4  5  6  7  8  9 10 11

 Writing integer equal to width specifier
 (11(I2,1X))

 1  2  3  4  5  6  7  8  9 10 11
Press any key to continue . . .

The output is correct and consistent in both cases, but the format specifier "appears" to be mangled.  Code similar to this compiled with PGI generated a runtime error.  Is there a compiler flag for Intel that would catch this at runtime?

Ted

Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 12.0.5.221 Build 20110719
Copyright (C) 1985-2011 Intel Corporation.  All rights reserved.

I am developing a Fortran program that calls C functions, that in turn call Fortran (BLAS and LAPACK).  On Windows I use IVF and MSVC, and it all works fine. I have just started porting the program to Linux (on our cluster), and the first run crashed with SIGSEGV.  I have not had time yet to narrow down the crash location, but it occurs to me that it could be an issue of the compilers that are being used.

The Fortran is compiled with ifort, the C object files are currently compiled with gcc and statically linked, while BLAS and LAPACK are dynamic libraries, probably also built with gcc.  Is it a mistake to use gcc with ifort?  Presumably Intel C is also available on the cluster.

Thanks

Gib