Hi,

I am a beginner level programmer in Visual Fortran. I am currently learning Fortran on Visual Studio Professional 2012 with Intel Visual Fortran XE 2013. 

For the very first time, debugging works assuming the codes don't have any errors. However, I am getting an error showing "Field does not exist" when debugging the same code for a second time. The code works only for the first time again if I close the program and reopen it. I don't know what is the problem as I have no prior experience. 

Any help would be appreciated. Thank you.

I apologize if this is a known issue and being worked on, but I failed to locate any relevant thread on this.

module mykinds_m

   use, intrinsic :: iso_fortran_env, only : I2 => int16, I4 => int32

   implicit none

end module mykinds_m

module m

   use mykinds_m, only : I2, I4

   implicit none

   interface

      function f( i ) result(RetVal)

         import :: I4, I2

         !.. Argument list
         integer(I4), intent(in) :: i
         !.. Function result
         integer(I2) :: RetVal

      end function f

   end interface

end module m

module n

   use mykinds_m, only : I2, I4

   use m, only : f

   implicit none

   integer(I2), parameter :: i = 0

contains

   subroutine foo()

      integer(I4) :: j

      j = f( i )  !.. Note the type mismatch in argument as well as result

   end subroutine foo

end module n

Compiling with Intel(R) Visual Fortran Compiler 16.0.1.146 [Intel(R) 64]...
m.f90

m - 0 error(s), 0 warning(s)

I used this exe:

w_fcompxe_novsshell_2013_sp1.3.202.exe

to install the compiler without having any Visual Studio installed.  I had expected that a shell of VS2010 or 2008 would come with it, but it did not.  How come?

I was looking to use the FEAST Eigenvector routines in a new program. The error message I get after linking to the MKL parallel library is libiomp5.lib not found.  This is a clean setup on a new computer for Windows 10, VS2103 and Latest Intel compiler.  As a test  I recompiled my old friend MagniCSR which uses MKL and Pardiso and it also gave the same error.

I had set the fortvars for the distributions.  Do I need to include the library directory in the properties?  This was not set for MAGNICSR - copying it over and adding the lib file to the solution - solves the problem - but seems a bit brute force.  I did the same for EIGEN System and that worked?

Would I be better off with 64 bit programs - rather than the default 32 bit for this type of problem?

Steve: Can I use some of the sample code for eigensystems in my programs?

Thanks

A quick question, When using the options /Qipo  /Qopt-report:3 we  get the optimisation report at link time (ipo_out.optrpt) but we also generate a .optrpt file (of zero size) for every source file at compile time. Is there any way of suppressing this unnecessary clutter? Also when you do a "clean" on the project the .optrpt files remain (VS2013/Compiler 16 update 1). I have seem somewhere the list of wildcards for files when doing a clean but having just looked today I can't find it. Could someone point me in the right direction.

Thanks, Andrew 

Will the 2016 compiler work using VS2016?  I know it isn't listed in the system requirements, so it is unlikely.  When is it likely to be working?

Hello, I am attempting to make use of a number of fortran functions and subroutines in a C++ project by using a generated .lib file. When compiling my C++ project, I get a linker error:

error LNK2019: unresolved external symbol _Leakage_SPH referenced in function

The function is called with Leakage_SPH (note no underscore), so I think this is the root of my problem. When I check the fortran code for this subroutine, I see:

Subroutine Leakage_SPH(Nu0,FracLkgTot,tlkg,NHoles,
     +                       ObjDat, holeAreas, holeHeights)

!DEC$ATTRIBUTES DLLEXPORT, C :: Leakage_SPH
!DEC$ATTRIBUTES ALIAS : '_Leakage_SPH' :: Leakage_SPH
!DEC$ATTRIBUTES REFERENCE :: FracLkgTot

This appears to give an alias of _Leakage_SPH so that the definition can be found. But something isn't working. The code compiles in fortran and the library is generated and placed in the correct spot. One thing I noticed is this remark that I get when compiling the fortran code:

remark #5082: Directive ignored - Syntax error, found ':' when expecting one of: , <END-OF-STATEMENT> ;

This appears to be pointing to my ALIAS line. Can anyone see what error I've made? Apologies if I've messed up any formatting; this is my first time posting on this forum (and indeed, my first time working with fortran at all as I usually work in C++). Thanks.

Hello,

On my Windows 7 64 bit PC I am using Intel(R) Visual Fortran Composer XE 2011 Integration for Microsoft Visual Studio* 2008, 12.0.3470.2008.

I have a large piece of inherited code that uses different modules containing objects with the PROTECTED attribute. For read and write access to these objects outside the module that it is defined in, get and set routines have been defined in the relevant module. INTERFACE statements have been defined to access these routines from outside these modules. Attached is an example of this set-up in a simple project.

Recently I have upgraded to Intel® Parallel Studio XE 2016 Update 1 Composer Edition for Fortran Windows* Integration for Microsoft Visual Studio* 2013, Version 16.0.0058.12. The compiler now throws an error compiling the same project:

Error 1 error #7993: A use associated object that has the PROTECTED attribute shall not appear as an actual argument if the associated dummy argument has the INTENT(OUT) or INTENT(INOUT) attribute. [MYDATA] .\test\main.f90 15

So it appears that for the new compiler I am not anymore able to modify the object from outside the module that it is defined in, even not through dedicated functions. Since this construction is used throughout this large piece of code, I was hoping that somebody has a bright idea towards resolving this issue? A simple way out is off course removing the PROTECTED attribute, but maybe there is a more neat way of doing this?

Best regards,

Koen

hello

i use intel compiler visual stdio(intel parallel 2015) to compile my project

console ( c source )

#include <stdio.h>
#include <stdlib.h>
#include <conio.h>
#include <string.h>
//#include <iostream>
//#define readfile readfile_

extern void readfile(char*, int*);

int main()
{
    int n, count;
    char Fname[9];
    char Name[10];

    strcpy(Fname,"AMIN.for");
    fprintf( stderr, "%s\n", Fname);

    readfile( Fname, &n, strlen(Fname));
    fprintf( stderr, "n = %d\n", n);
//  fprintf( stderr, "%s\n", Name);
    getch();
    getch();
    return 0;
}

subroutine ( Lib fortran )

      subroutine readfile( fname1, m )
      character fname1*(*)
      integer m
      integer iounit,i
      iounit=15
      write(*,*) fname1
c10   format (a9)
      open(iounit,file = fname1,action='read')
      read (iounit,*) m
c20    format (i10)
      write(*,*) m
      close(iounit)
      return 
      end subroutine

this is my project and i don't have a problem

in this line i have a great problem

readfile( Fname, &n, strlen(Fname) );

i need to change line  ( is necessary for me)

readfile( Fname, &n);

is it possible? how to call without lenght character or how to calling convert to run and compile it correctly?

In addition i change "name case interpretation" to "lowercase"

when i compile it , my project cann't open file . i don't khnow why.

how to change setting vs2012 toget to it?

Thanks

Installation of Intel Parallel Studio XE failed.

Error message is:  "package signature verification failed"

Tried this "solution":  https://software.intel.com/en-us/articles/intel-parallel-studio-xe-insta...

Didn't work. Still can't install Parallel Studio.

Any suggestions?

I

This is the second of the Harrison programs that I put into IFORT.

it runs quite nicely, but there is a slight weirdness, there is a do loop - 160 - which uses I as the index at the start of the program - the second half of the program includes a loop generation with a straight goto 160 back to the 160 continue.  The compiler warns that it is jumping into a block, but the code works fine and gives the correct -as far as I can tell answers.  The second part of the program uses a rather interesting method to set I from 1 to 4 for the input file - rename as a.inp and prints out the results

    Write(*,1010)I
1010 FORMAT(//11H MEMBER NO.,I3/)
    Write(*,*)' L/SET AX.TENSION MAB-Z-AX1S MBA-Z-AXIS MAB-Y-AXIS MBA-Y-AXIS   TORQUE'

So as a simple first step to get rid of the goto warning I put a 161 continue after the 160 loop. Compiled but it only went through the output loop once and only put out member 1 not 2 and 3 as shown in the capture image. Going back to the loop 160 jump works. I put in some simple print statements - but they do not appear to print in the logical order I would expect.  Here A and Here ISW should print each time through the loop, but they do not.

I am missing something simple - I tried several variations on loops and just lost the output all together.  So I am stumped and I would prefer not to rewrite more extensively as the program is short and sweet. I will fix the arthimetic if's but not till I solve this little problem

John

I inherited a complex application that is written in the fixed form. It has about 100 000 lines of code (without comments) based on what cloc.exe I found on Internet calculated.

My question is - as the fixed form is obsolete, should I consider changing it to free form? If this is recommended, is there any tool.that could make this process at least partly automatic?

Hi,

I have a problem similar to the one described in the topic https://software.intel.com/fr-fr/forums/intel-visual-fortran-compiler-for-windows/topic/296547 but not exactly the same.

I have a dll which contains numerous exported functions. These functions use the STDCALL calling convention along with the REFERENCE and ALIAS attributes. Some of them are calling other entry points. If I place the interface declaration of the called routine in the calling one everything works correctly. Recently I have created a Fortran module wich contains all the interface déclarations for all the exported routines. My problem is that if I use this module into an exported routine which calls another exported one, it seems that the export vanishes.

Example that works:

subroutine FUNC1(arg)
!dec$ attributes stdcall, reference, alias:'Func1', dllexport :: FUNC1
!dec$ attributes stdcall, reference, alias:'Func2' :: FUNC2

.../...

call FUNC2(arg)

end subroutine FUNC1

subroutine FUNC2(arg)
!dec$ attributes stdcall, reference, alias:'Func2', dllexport :: FUNC2

.../...

end subroutine FUNC2

Example that does not work :

module Interfaces_Decl

interface
subroutine FUNC1(arg)
!dec$ attributes stdcall, reference, alias:'Func1' :: FUNC1
    real(8), intent(in) :: arg
end subroutine FUNC1
end interface

interface
subroutine FUNC2(arg)
!dec$ attributes stdcall, reference, alias:'Func2' :: FUNC2
    real(8), intent(in) :: arg
end subroutine FUNC2
end interface

end module Interfaces_Decl

subroutine FUNC1(arg)
!dec$ attributes stdcall, reference, alias:'Func1', dllexport :: FUNC1
use Interfaces_Decl

.../...

call FUNC2(arg)

end subroutine FUNC1

subroutine FUNC2(arg)
!dec$ attributes stdcall, reference, alias:'Func2', dllexport :: FUNC2

.../...

end subroutine FUNC2

In this case the FUNC1 routine is no more exported and I don't know why.

Furthermore, in case of an unresolved external symbol in FUNC1, the error message is mentionning FUNC1 instead of Func1. This seems to indicate that the interface declaration has changed.

I don't understant what I am doing wrong.

Note 1: if I use

use Interfaces_Decl, only: FUNC2

the problem disappear.

Note 2: if I try to add the DECORATE attribute in both déclarations (module and routine) I get the same error message as in the mentionned topic:

error #7794: Only a function or subroutine subprogram may have the !DEC$ ATTRIBUTES directive DECORATE specifier. [FUNC1]

Best regards,

Phil.

I'm having a Fortran 77 problem passing an allocated  user-defined Type array to a subroutine.  The subroutine compiles first without errors.  The calling program complains that the actual argument differs from the dummy argument.  The array has the same Type structure in both the sub and calling program. I'm using compiler v16.0.  I'd appreciate your help with this.  

Calling program:
          type bounds
             real*8::fromth=0d0,toth=0d0,fromph=0d0,toph=0d0
          end type
          type(bounds),dimension(:),allocatable::elbounds
          integer num
          num=100
          allocate (elbounds(num))
          call sub(num,elbounds)

Subroutine:
          subroutine sub(num,elbounds)
          integer num
          type bounds
             real*8::fromth=0d0,toth=0d0,fromph=0d0,toph=0d0
          end type
       type (bounds)::elbounds(num)   

Nowhere does it tell us what USE statements to put into our source code.

at least nothing that works.

I tried USE LAPACK, LAPACK95, BLAS, BLAS95, and 

include MKL.FI

None of those will compile.

Why dont they give ONE example of something that actually works ?

I am bringing this up because of an issue I just found - - -

I have two routines, one compiles and the other does not, both using the same USE statements.

At first, I though it might be the computer environment, because they were on two differnet computers.

however, since both are NOW on the same computer, and I get the same error messages.

One generates 7002 errors, having to do with the USE path.

They are on the same computer, same compiler, using the same VS 2010 shell.

The only thing I can think of offhand is the PROJECT settings. However, so far, I haven't found anything obvious that would cause the compiler to reject a USE statement because of the project settings. Maybe you would know ?

I have the latest compiler download, and WINDOWS 10.

I just purchased "Intel® Parallel Studio XE 2015 Composer Edition for Fortran, Windows with Rogue Wave IMSL for Windows". Before I begin the installation I would like to ask the community if I also need to purchase Microsoft Visual Studio 2015. and if Yes how do I proceed with the installation. DO I first install Visual Studio and the Intel Fortran or vice-versa.

Thank you very much in advance

I'm not really experienced in Fortran, I tried unsuccessfully to call a Windows API function as a test (previously I tried some other tests such as locking the screen, with success).
The function is QueryProcessCycleTime (just for curiosity, it retrieves the cpu cycles count of a process, in my test code with a fixed pid of an actually existent process). Its syntax:

BOOL WINAPI QueryProcessCycleTime(
  _In_  HANDLE   ProcessHandle,
  _Out_ PULONG64 CycleTime
);

I couldn't find the Fortran "translation" for these data types and I tried several combinations in my code (for each variables) with no luck. I compiled with
ifort /libs:static /exe: ...   or
ifort /libs:qwin,static /exe: ...
but the output is always:
 F                  4936                     0
 (return value,  pid,  cycles count).

The function doesn't appear in the kernel32.f90 supplied by Intel (see Calling Windows API Routines for syntax not involving ISO_C_BINDING).
 
Going beyond the specific test I wondered if:
really Fortran can't load dlls supplying full path (without adding it as an environment variable)?
Or more in general and in a few words:

Can Fortran be used as a Win32 programming language?
(I don't mean only for a limited set of functions)

Or, at the end, is it (very, we know) useful only for number crunching?

My test code:

module process_cpu_cycles
use ISO_C_BINDING
implicit none

public QueryProcessCycleTime
interface
    function QueryProcessCycleTime(proc_id, cpu_cycles) bind(C,Name='QueryProcessCycleTime')
        use ISO_C_BINDING
        implicit NONE
        !DEC$ ATTRIBUTES STDCALL :: QueryProcessCycleTime
        logical(C_BOOL) :: QueryProcessCycleTime        ! tried C_INT too
        integer(C_INTPTR_T), value :: proc_id           ! tried without value
        integer(C_INTPTR_T), value :: cpu_cycles        ! tried C_INT64_T too
    end function QueryProcessCycleTime
end interface

end module process_cpu_cycles


program cycles
use process_cpu_cycles
use ISO_C_BINDING
implicit none

logical(C_BOOL) :: ret_val
integer(C_INTPTR_T) :: pid
integer(C_INTPTR_T) :: ccycle        ! tried C_INT64_T too

ccycle=0
pid=4936
ret_val = QueryProcessCycleTime(pid,ccycle)
write (*,*) ret_val, pid, ccycle
end program cycles

We used to work with static library and now decided to switch to dll. Here is the problem that we are facing. I have a large source file that contains hundreds of subroutines, but they can be classified into two kind of subroutines, one kind is the system subroutines (syssrc.for) which can not be reached by the users, while the other kind is the user subroutines (usr.for which are called by some routines in syssrc.for) which users can modify or print out some data from them.

The procedure I did is that,

1.  Add  !DEC$ ATTRIBUTES DLLEXPORT :: "nameofsubroutines" under every subroutines in usr.for.

2. Build dll using usr.for to generate dllusr.dll and dllusr.lib files.

3. Add   !DEC$ ATTRIBUTES DLLEXPORT :: "nameofsubroutines" under every subroutines in syssrc.for

4. Build dll using syssrc.for and dllusr.lib (need dllusr.dll in the same folder), to generate dllsyssrc.dll and dllsyssrc.lib.

5. Create a application with main program and link dllsyssrc.lib. 

In this way, I could call the subroutines in both usr.for and syssrc.for. But the usr.for that should be modified by users can not be overwritten or replaced the one in usr.for since these subroutine are embedded in dllsyssrc.lib.

Does anyone has idea what kind of modifications or configurations should I set to let the project ignore the usr.for in dllsyssrc.lib and use the updated one?

Thank you

Hello, 

I have read about the instructions to share data in dlls in this link 

https://software.intel.com/en-us/node/535307

However, I can not see how to share multiple common blocks in one statement. I did the following

	!DEC$ ATTRIBUTES DLLIMPORT :: /CMPNTR/,/GENC/,/NUMS/,/CONSMD/,
     +	/CMMASS/,/USRSTE/,/ORNTCR/,/CRPVAR/,/CONTVR/,/FFTCOM/,/RDUNIT/

and got no error. But only the first line become green, can I assume that I need multiple directives for each line?

Also, if the export directives are defined in this way, when other subroutines use one of these common block, do it have to follow the same declaration again, since it requires the detail definition of each common block when refered and it is not quite convenient.

Thank you