Hello,

After a break of several years i am back again to use IVF. I am working on an old (converted) CVF  quickwin project consisting approx. 50 fortran-files. The program compiles in debug and release (both win32) mode without any warning and error. When I start the program it stops immediately with the message:

STATUS_STACK_BUFFER_OVERRUN encountered

No more. Unfortunately I have no idea where to search for the problem. Ideas will be appreciated. I havened found an idea based on an search in the forum.

I am using: Intel® Parallel Studio XE 2018 Update 1 Composer Edition for Fortran Windows* Integration for Microsoft Visual Studio* 2015, Version 18.0.0037.14,

Thanks in advance

Frank

Dear Fortran black-belts and others,

I am trying to understand the rules governing the passing of parameterised derived type variables as arguments into subroutines and functions. Here is an example type definition from my program:

      TYPE CoeffPairSpeciesDescr (nSpecies1, nSpecies2, nValuesMax)
C
        INTEGER, LEN :: nSpecies1, nSpecies2, nValuesMax
        INTEGER :: Species(nSpecies1, nSpecies2)
        INTEGER :: nValues
        DOUBLE PRECISION :: Value(nValuesMax)
C
      END TYPE

After creating the parameterised derived type variable (which I only need to do once, at the start of a program run), I can only find two ways of passing it as an argument to other routines:

(1) By declaring it in the routines like this:

  TYPE (CoeffPairSpeciesDescr(:,:,:)), ALLOCATABLE :: AlphaObject

where "AlphaObject" is the parameterised derived type variable.

(2) Or, like this:

  TYPE (CoeffPairSpeciesDescr(NA,NB,NC)) :: AlphaObject

where NA, NB, and NC are integers whose values are known (and are the values used when the variable was allocated).

If I change the statement in (1) above to remove "ALLOCATABLE," I get the compiler error message:

test_3.for(133): error #8730: A colon may only be used as a type parameter value in the declaration of an object that has the POINTER or ALLOCATABLE attribute.

I don't understand why this should be. An ordinary array (ie, not a derived type) does not behave in this way. As Steve Lionel explained in a post several years ago:

"That an array is allocatable does not, in itself, change how you pass it to a routine. If you had an F77-style program where you changed one array to be allocatable, and allocated it, you would not have to change any other code in the program."

Why don't parameterised derived types behave in the same way? It seems odd that the parameterised derived type variable apparently has to either be declared as allocatable in every subprogram it is passed to, or declared with explicit values given to the "LEN" attributes. What am I missing?

All explanations gratefully received.

Simon C.

I use intel visual fortran compiler 2018 update 2 version and visual studio 2017 community version.

Whenever I open visual fortran projects or solutions, it just terminates with "no response" indicator. 

Fortunately, it is possible to open fortran projects through visual studio start page. (Run visual studio -> Open existing projects)

I have no idea about why this is happening. Has anyone ever experienced this?

I am getting an intermittent error in the dialog box module within a fortran windows application and am trying to track down the cause. The stack traceback indicates that the crash occurs in the ControlAddString function, called from DlgSetChar and DlgModal within iflogm module. The error given is Access Violation but I only get the disassembly listing in the debugger. I'm using the latest version of the compiler (18.2) though I am sure that in previous versions I was able to step into the modules such as iflogm but this no longer seems to be the case.

Often when I simply relaunch the application from within the debugger everything appears to work fine making it difficult the find the root cause of the problem. It would be helpful if the source of the iflogm modules could be made accessible to the debugger so that I can interrogate the variables in the dialog structure. Is this still possible and if so how can I set up VS 2015 debugging to achieve this?

Has anyone else had similar issues? Any ideas would be appreciated.

Has anyone got any ideas on fixing this issue

With PXE2018 Update 2, I have just migrated from MSVS2015 to MSVS2017.

With 2015, I can always open the last solution by opening MSVS.

With 2017, opening MSVS hangs while trying to open the last solution (opens 1 of 4 projects and hangs).  After exiting, and reopening MSVS which starts without any solutions loaded; I can then open the solution without any problems.

Why can't I automatically open the last solution?  Any hints?

Our code has been compiling fine for years and now when we try to use anything newer than IFC 2015 Update 3 we are running into problems.  If we compile with IFC 2015 Update 5, a certain part of our program, when executed, produces zeros, when we should be getting a long list of data.  I cannot even get update 4 to install.  As soon as the loader for update 4 runs and I click next it closes.

I need to know what changes took place from IFC 2015 Update 3 to Update 5.

My organization has recently upgraded the Intel compiler we use for our software from Intel Fortran 2013 SP1 update 3 to Intel Fortran 2017 update 6.

However, we have observed that our software now encounters from stack overflows for both non-optimized debug and optimized release runs of the ifort2017u6 build, whereas corresponding ifort2013u3 builds both run without any stack overflow encountered. These builds are using the same source code and compiler settings were set to be effectively similar.

This is concerning to us, since we do have a deliberately capped /STACK reserve size for our software and we don't want to be unable to run any simulations that previously ran.

I was also able to corroborate an increase in stack memory usage using the new compiler by comparing the loc() address of an integer at the top of the call stack with a loc() of a local further down. If I compare the stack memory address for the routine that encounters the overflow, I see it corresponds to about 15% more stack memory usage.

I'm seeking to learn about any programming styles that may cause the new compiler's stack memory usage to swell compared to the older 2013 SP1 update 3 compiler, and/or if there are any Intel tools that may help troubleshoot this change in stack memory usage problem.

Hey,

we use the function WriteFile from the MSFWIN module. Unfortunately we had some issues after updating von 18.0.1 auf 18.0.2.. We found out that the interface was changed so that lpNumberOfBytesWritten now is not exspecting anymore LOC(anyInt), instead you just need to pass the integer because of a change in the compiler settings. Was this change intended?

18.0.1 kernel32.f90:

INTERFACE 
FUNCTION WriteFile( &
        hFile, &
        lpBuffer, &
        nNumberOfBytesToWrite, &
        lpNumberOfBytesWritten, &
        lpOverlapped)
import
  integer(BOOL) :: WriteFile ! BOOL
    !DEC$ ATTRIBUTES DEFAULT, STDCALL, DECORATE, ALIAS:'WriteFile' :: WriteFile
  integer(HANDLE) hFile ! HANDLE hFile
  integer(LPCVOID) lpBuffer ! LPCVOID lpBuffer
  integer(DWORD) nNumberOfBytesToWrite ! DWORD nNumberOfBytesToWrite
  integer(DWORD) lpNumberOfBytesWritten ! LPDWORD lpNumberOfBytesWritten
!DEC$ ATTRIBUTES REFERENCE, IGNORE_LOC, ALLOW_NULL :: lpOverlapped
  TYPE (T_OVERLAPPED) lpOverlapped ! LPOVERLAPPED lpOverlapped
 END FUNCTION
END INTERFACE

18.0.2 kernel32.f90:

INTERFACE 
FUNCTION WriteFile( &
        hFile, &
        lpBuffer, &
        nNumberOfBytesToWrite, &
        lpNumberOfBytesWritten, &
        lpOverlapped)
import
  integer(BOOL) :: WriteFile ! BOOL
    !DEC$ ATTRIBUTES DEFAULT, STDCALL, DECORATE, ALIAS:'WriteFile' :: WriteFile
  integer(HANDLE) hFile ! HANDLE hFile
  integer(LPCVOID) lpBuffer ! LPCVOID lpBuffer
  integer(DWORD) nNumberOfBytesToWrite ! DWORD nNumberOfBytesToWrite
  integer(DWORD) lpNumberOfBytesWritten ! LPDWORD lpNumberOfBytesWritten
!DEC$ ATTRIBUTES REFERENCE, IGNORE_LOC, ALLOW_NULL :: lpNumberOfBytesWritten
  TYPE (T_OVERLAPPED) lpOverlapped ! LPOVERLAPPED lpOverlapped
!DEC$ ATTRIBUTES REFERENCE, IGNORE_LOC, ALLOW_NULL :: lpOverlapped
 END FUNCTION
END INTERFACE

Dear All

I have a F77 code to solve for a system of nonlinear equations. The code works well and gives me correct results when I compile it using gfortran. However, the same code returns me initial guess, when I compile it using ifort. 

It seems the code does not undergo iterations to change the initial guess to the final values.

Any suggestion how to fix this?

I am collecting some routines that are in various modules into a static library library. These routines are common to a number of our programs. They take a long time to compile and are rarely changed; thus, at least to me anyway, are great candidates for extraction to a static library that will link with the programs that depend on them.

However, three of the routines I want to extract to the static library use functions from a module defined in each program itself. Here is the basic definition of the module:

      MODULE PROGRAMPROPERTIES
!-
      PUBLIC GET_PROGRAM_NAME
      PUBLIC GET_PROGRAM_VERSION
      PUBLIC GET_REVISION_DATE
      PUBLIC WRITE_PROG_DATA_TO_TRACE
!-
      CONTAINS
...
      END MODULE PROGRAMPROPERTIES

All of the public definitions are functions that are identically defined as follows:

      FUNCTION GET_PROGRAM_VERSION() RESULT(c_program_version)

      CHARACTER (LEN=200) :: c_program_version ! The Program Version

      END FUNCTION GET_PROGRAM_VERSION

Basically, the module exists in each program to return its name and version info, etc.

The three procedures will not compile without access to the module so I figure that a way around this is to declare an interface in the library procedures that would then call the functions in the PROGRAMPROPERTIES module in each program - that is assuming I understand the use of the interface keyword in FORTRAN. (While I have developed a taste for FORTRAN, I am primarily a C#/C++ programmer and understand the use on interfaces in that world quite well.)

Here is an example function that I want to extract to the static library. Note it contains a use statement for the PROGRAMPROPERTIES module, and that I am not the original author of the routines.

      FUNCTION OUT_REVISION () RESULT (i_void)
!-
      USE PROGRAMPROPERTIES
      USE COMMAND_LINE_FUNCTIONS
      USE F95_UTILITY_FUNCTIONS      
!-
      CHARACTER (LEN=200) :: c_file            ! ini file name
      CHARACTER (LEN=200) :: c_ident           ! Defines the identifier in the ini file
      CHARACTER (LEN=200) :: c_sect            ! Defines the section in the ini file
      CHARACTER (LEN=200) :: c_revision        ! Revision of the program
!-
      INTEGER i_10   ! The number 10
      INTEGER i_void ! Return Zero
!-
      c_revision = GET_REVISION_DATE() ! Returns the revision date of the program.
      i_void  = 0
!-
      c_file = ini_readcla_3 () ! Read the third command line argument
!-
      c_sect  = 'VERSION INFO'
      c_ident = 'REVISIONDATE'
      i_10    = 10
      i_void  = SET_CASE_SENSITIVE (.FALSE.)      
      i_void  = ini_writeppsl (c_sect,c_ident,c_revision,i_10,c_file)
!-
      END FUNCTION OUT_REVISION

Each function is itself contained in a module that I hope to make part of the static library.

I am looking for an example of how I would replace the use statement for the PROGRAMPROPERTIES module with an interface so that I can compile the library without the PROGRAMPROPERTIES module, and have the library routines call the module functions when necessary.

Anyone have any idea how to accomplish this?

Thanks in advance!

I am trying to run "ex_nlsqp_bc_f.f" example of MKL in Intel Composer XE 2013 and Visual Studio 2012, but I get the following errors:

mkl_rci.fi(158): error #5082: Syntax error, found '&' when expecting one of: *

I just run the example code without any alterations. Do you have any suggestion how to resolve this error?

Thanks

I have a license for 

Parallel Studio XE Composer Ed for Fortran Windows 2017.

I wanted to install it on a new machine but I couldn't.

It said product support has expired and didn't let me proceed. 

Can you help me with that?

DK

I have a parallel Fortran code I would like to run on the Windows system right now. The codes have a bunch of conditional compilation such as

#ifdef PARALLEL
#endif

#ifdef LOOSE
#endif

The following is the Makefile I got.

main_lc: modules.o ...(all the object files) \ 

mpif90 -o main.exe \

modules.o ...(all the object files)

modules.o: modules.f
mpif90 -DLOOSE -DPARALLEL -c   modules.f

...(all other object files )

After I got main.exe

then type following command to run the program

mpiexec -np 4 ./main.exe <input.inp> output

I was wondering if there is any way that I can make it compiler and run in Visual Studio?

Hi, I am doing some mixed programming between C++ and Fortran. A problem comes up about passing a character array from fortran to C++ as shown in the code. The memeory addresses before and after calling the subroutine are not consistant to each other thus the character array is not properly passed. Am I doing it the wrong way or is there anything I have not yet noticed ? Thanks for any help.

PS: The project was debugged on x64 platform.

I'm having a linker issue when building a Fortran DLL. I'm using the following:

• Visual Studio 2015 with Update 3
• Parallel Studio 2016 with Update 3

Here's a description of the projects involved:

• CommonSource project:
  • Output: C++ static library
  • Contains a .cpp/.h source that specifies the following method:

    • Log.h
      void CLOSE_LOG();

    • log.cpp
      void CLOSE_LOG()
      {
          g_OutStream.close();
      }

• Subroutine project:

  • Output: Fortran static library

  • 'Additional Include Directories' points to Debug directory of the CommonSource project

  • Contains a .for source that calls on the CLOSE_LOG method:

    • exit_model.for
      SUBROUTINE EXIT_MODEL(A_MESSAGE)
          ...
          CALL CLOSE_LOG
          ...
      END SUBROUTINE EXIT_MODEL

• DLL project:

  • Output: Fortran DLL

  • 'Additional Dependencies' includes the CommonSource and Subroutine static libraries

  • Contains a .for source that calls on the CLOSE_LOG method:

    • name.for
      FUNCTION NAME()
          ...
          CALL CLOSE_LOG
          ...
      END FUNCTION NAME
      

Individually, both 'CommonSource' and 'Subroutine' projects build successfully. However, when building the DLL project I get a link error on the 'CLOSE_LOG' call in exit_model.for of the Subroutine project. However, an error is not shown for the same call in name.for.

Why would the link error occur in an accompanying dependency (Subroutine) and not the DLL project itself? How can this issue be resolved?

Hi I am new with VS 2018 community for windows 10 for Abaqus 2017.  I run with command line compiler but have the following message while I tried to create an exe file. 

ifort vumatsmc.f
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 18.0.1.156 Build 20171018
Copyright (C) 1985-2017 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 14.13.26129.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:vumatsmc.exe
-subsystem:console
vumatsmc.obj
LINK : fatal error LNK1104: cannot open file 'libucrt.lib'

What is needed to resolve the issue?

Thanks,

Jong

Join the Intel® Parallel Studio XE 2019 Beta Program today and—for a limited time—get early access to new features and get an open invitation to tell us what you really think.

We want YOU to tell us what to improve so we can create high-quality software tools that meet your development needs.

Sign Up Now >

Top New Features in Intel® Parallel Studio XE 2019 Beta

• Scale and perform on the path to exascale. Enable greater scalability and improve latency with the latest Intel^® MPI Library.
• Get better answers with less overhead. Focus more fully on useful data, CPU utilization of physical cores, and more using new data-selection support from Intel^® VTune^™ Amplifier’s Application Performance Snapshot.
• Visualize parallelism. Interactively build, validate, and visualize algorithms using Intel® Advisor’s Flow Graph Analyzer.
• Stay up-to-date with the latest standards:
  • Expanded C++17 and Fortran 2018 support
  • Full OpenMP* 4.5 and expanded OpenMP* 5.0 [DRAFT] support
  • Python* 3.6 and 2.7

New Features in Intel® Fortran Compiler

• User-defined reductions, completing support for OpenMP* 4.5
• BLOCK construct inside an OpenMP parallel region
• Array shape checking
• Coarray Events for synchronization of different coarray images

To learn more, visit Intel^® Parallel Studio XE 2019 Beta page.

Then sign up to get started.

I joined the 2019 beta program and initiated the install. The scroll down in step 2 says that the Fortran 18.0 integration in VS has been detected and will be removed if 2019 beta is integrated into VS. I went no further. Is that actually true? I'm running VS 2017 with Fortran 18.02 integrated.

I have just upgraded my fortran IDE to the INTEL Parallel Studio XE Composer Edition for Fortran Windows. I am currently having difficulty creating a new static library of subroutines that I have developed over the years. The existing static library, which I made using my previous version of visual studio, works fine. But when I create a new version of this library, I get the error messages shown in the attached.

Hello, the program below is accepted by gfortran and PGI fortran, but not by Intel Fortran (versions 15, 17), unless I remove the "extends" clause.

The error message is:

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

vs_intel.f90(64): error #6197: An assignment of different structure types is invalid.
    c = a + b
----------^
compilation aborted for vs_intel.f90 (code 1)

The program is this:

! vs_intel.f90 --
!     Problem with Intel 15 and 17 compiler
!
!     It seems the "extends(vector)" part is the problem!
!
module vectorspaces
    implicit none

    type :: vector
    end type vector

    interface operator(+)
        module procedure addition
    end interface

contains
function addition( a, b )
    class(vector), intent(in)  :: a
    class(vector), intent(in)  :: b
    class(vector), allocatable :: addition

    allocate( addition )
end function addition

end module vectorspaces

!
! Test this with an actual implementation
!
module vectors_3d
    use vectorspaces

    type, extends(vector) :: vector_3d !<== remove the "extends" clause and it is accepted
   !type :: vector_3d
        real, dimension(3) :: coords
    end type

    interface operator(+)
        module procedure add_3d
    end interface

contains
function add_3d( a, b )
    type(vector_3d), intent(in)  :: a
    type(vector_3d), intent(in)  :: b
    type(vector_3d)              :: add_3d

    add_3d%coords = a%coords + b%coords
end function add_3d

end module vectors_3d

! Test program for the vector space modules
!
program test_space
    use vectors_3d

    implicit none

    type(vector_3d)                :: a, b, c

    a = vector_3d( [1.0, 1.0, 1.0] )
    b = vector_3d( [2.0, 2.0, 2.0] )
    c = a + b
end program test_space

I do not see what is wrong with it. (I stumbled on this problem when preparing a slightly larger program) If I remove the interface block for operator(+), it is also accepted, but the error message does not hint at an ambiguity.