Hi everyone,

I am having trouble just running the code.  What I did is that I just change the intel environment to be ready to run openmp. (Generate Parallel Code \Qopenmp)  Even WITHOUT writing anything related to omp in my code, i.e., "USE omp_lib, CALL set_num_threads, !$omp pararell do", I have Stack Overflow Error.  That means this also happens after I type all omp directives as well.

I tried to set stack_reserve_size, but it does not work.  Either stack over flow error, or the runtime screen just pops up and disappears if stack size is too large.

Any suggestion ?  I am using IA-32 platform and I am not sure whether it is due to this.

Thanks.

I am using make for a project and include a few directories on the command line to look for include files in.

My question is, how do I find out after the make is complete which exact file ifort used during the make process for a given source file?

Sometimes there are multiple include files with the same name in different directories, etc. I know ifort will complain if it cannot firgure it out uniquely, but how do I found out which include file was used for a specific compile of a certain file after the making is finished?

Hi all, I'm running in an error:

"forrtl: severe (66): output statement overflows record"

ifort - v says I'm running "Intel(R) 64, Version 17.0.2.187 Build 20170213" in MS Studio Community 2015

I am writing a very long line to a file with 1007 columns, the following statement gives the error

WRITE(16,'(2G13.3, 2I3, 2G10.2, I4, 1200(1X,G15.8,1X,E12.6))')& X, Y, N, IH, ZT, ZB, NH,  ( PROP(M), FLAG(M) , M=1, SIZE(PROP) )   

Note:
-statement simplified for this post
-unit 16 is well defined
-the value of '1200' in the format is always larger than SIZE(PROP)

I changed the code to first do an internal write to "out_test", where this variable has a large enough size:

CHARACTER(35000) :: out_test

so instead of the above, I do

WRITE(out_test,  <SAME FORMAT ETC.>

this works until I try to write it to a file:

WRITE(16,'(A)') trim(out_test)

Again same error.

this however works (but contains line breaks in the output I want to avoid):

WRITE(16,*) trim(out_test)

Any hints?

Cheers

-Ralf

I have the same question that seems to still be a problem in Intel Fortran XE 2016 integrated with Visual Studio 2015.  I create a shared section (memory) in a DLL and change the values via FORTRAN.  The code is working fine; however, when I try to change the value in the debugger, the shared memory does not get written.

 The code for the shared section is this:

extern "C"

{

#pragma data_seg(".MYSEC")

__declspec (dllexport) char abcbuffer[ABCSIZE] = { 0 };

#pragma data_seg()

#pragma comment(linker, "-section:.MYSEC,rws")

}

The code for the FORTRAN program is this:

program FortranExecutable

implicit none

 

INTEGER*4 VAR1

INTEGER*4 VAR2

 

COMMON /ABCBUFFER /

& VAR1,VAR2

!ms$attributes dllimport :: ABCBUFFER

!ms$attributes C, alias : 'abcbuffer' :: ABCBUFFER

PRINT*, VAR1

PRINT*, VAR2

 

VAR1 = 123

VAR2 = 234

 

PRINT*, VAR1

PRINT*, VAR2

 

READ(*,*) VAR1,VAR2

 

end program FortranExecutable

When I run the program I get the following output:

0

0

123

234

When I run the program a second time while the first is still running, you can see that the shared memory is set and I get the following output:

123

234

123

234

Now if I start again and break in the first program before the second set of "prints" and set the value VAR1 to 777, the "prints" will see the new value

0

0

777

234

But if I run the program a second time, the second program does not see the value changed through the debugger and I get the following again:

123

234

123

234

Why is it when the value is changed in the debugger, the second program does not see the change?

I attached the program.

I'm trying to write a precompiler that processes a bunch of variable declarations in an include file.  These variables are tied to shared memory so I also need to do  a bunch of call C_F_POINTER. Then the FORTRAN file contains some variable declarations of their own.  So I have something like this in the include file:

      REAL*8, POINTER :: F0
      call C_F_POINTER (SM02, SMARR02, [2000])
      call C_F_POINTER(C_LOC(SMARR02(1)), F0)

And something like this in the FORTRAN file:

include 'IncludeExample.inc'
REAL*8 ABC1
ABC1 = F0

This unfortunately complains : A specification statement cannot appear in the executable section

Is there another way to create my precompiler to process my variable in the include file?  It would be nice is FORTRAN could mix declarations and executable sections.

When the below command executes, it read the file content (    35) where all the spaces are ignored and it reads only the numbers in that case the size of the number is only 2 bytes, but we are trying to read 8 byte number which throws the exception.

FORMAT(I8)

IF I use FORMAT(I2) then there is no exception

      program test

      INTEGER(4) IRATE

      OPEN(4,file='C:\Srini\Files\Arat51',status='OLD',access='DIRECT',

     &               form='FORMATTED',recl=8)

      Read(4,200,rec=2)IRATE

      CLOSE(4)

200   FORMAT(I8)

      STOP

      end

I am still hoping to be able to use UDDTIO in our Fortran programs before retirement, but time is running short. While the v17 compiler corrects a few of the many bugs I signalled, it manages to introduce new, fascinating ones like this:

module m_test
   type t1
        integer :: a
      contains
        procedure, private :: r_t1
        generic :: read(formatted) => r_t1
    end type
    contains
        subroutine r_t1(dtv, unit, iotype, vlist, iostat, iomsg)
            class(t1),          intent(inout)   :: dtv
            integer,            intent(in)      :: unit
            character(len=*),   intent(in)      :: iotype
            integer,            intent(in)      :: vlist(:)
            integer,            intent(out)     :: iostat
            character(len=*),   intent(inout)   :: iomsg
            read(unit, fmt="(i4)", iostat=iostat, iomsg=iomsg) dtv%a
        end subroutine
end module

program test
    use m_test

    character(len=:), allocatable :: str
    type(t1) :: x,y,z
    str="111122223333444455555"
    read(str, fmt="(DT,DT,DT)") x,y,z
    print *, x%a, y%a, z%a
    read(str, fmt="(3DT)") x,y,z
    print *, x%a, y%a, z%a
end program

when compiled and run gives this.

C:\dev\f95\bugs\intel>ifort test.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.4.210 Build 20170411
Copyright (C) 1985-2017 Intel Corporation.  All rights reserved.

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

-out:test.exe
-subsystem:console
test.obj

C:\dev\f95\bugs\intel>test
        1111        2222        3333
forrtl: severe (125): A derived type variable in this statement requires a DT format specifier because it has a component that is ALLOCATABLE, POINTER, or PRIVATE, unit -5, file Internal Formatted Rea
d
Image              PC                Routine            Line        Source
test.exe           00007FF7CDF4E9CD  Unknown               Unknown  Unknown
test.exe           00007FF7CDF39226  Unknown               Unknown  Unknown
test.exe           00007FF7CDF31569  Unknown               Unknown  Unknown
test.exe           00007FF7CDFA024E  Unknown               Unknown  Unknown
test.exe           00007FF7CDFA05E5  Unknown               Unknown  Unknown
KERNEL32.DLL       00007FFA1AA216AD  Unknown               Unknown  Unknown
ntdll.dll          00007FFA1B8154E4  Unknown               Unknown  Unknown

C:\dev\f95\bugs\intel>

If I simply change the order of the two read statements:

...
program test
    use m_test

    character(len=:), allocatable :: str
    type(t1) :: x,y,z
    str="111122223333444455555"
    read(str, fmt="(3DT)") x,y,z
    print *, x%a, y%a, z%a
    read(str, fmt="(DT,DT,DT)") x,y,z
    print *, x%a, y%a, z%a
end program

it seems to run ok:

C:\dev\f95\bugs\intel>ifort test.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.4.210 Build 20170411
Copyright (C) 1985-2017 Intel Corporation.  All rights reserved.

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

-out:test.exe
-subsystem:console
test.obj

C:\dev\f95\bugs\intel>test
        1111        2222        3333
        1111        2222        3333

C:\dev\f95\bugs\intel>

the compiler v16 update 4 does not expose this problem.

A solution with several C and Fortran projects has been converted from XE2016 with VS2010 to  XE2018 Beta with VS 2017. All the Fortran resource files (with just version info in the RC files) were converted without error. But the version info. was not found in the output binary (EXE file). When the RC files were edited, an error message was shown (a symbol with this name already exists). After viewing or editing the resource file(s), some C files were not shown correctly under the C project and some C files got removed from the project. The workaround is to delete the RC fil(s) and recreate new RC files.

Does Intel Fortran student version has OpenMP and MPI?

I am new to parallel programming. I got this error when I run the following code.

------------------------------------------------------------------------------------------------------------------

1>Console1.obj : error LNK2019: unresolved external symbol _OMP_GET_THREAD_NUM referenced in function _MAIN__
1>Console1.obj : error LNK2019: unresolved external symbol _OMP_GET_NUM_THREADS referenced in function _MAIN__
1>Debug\Console1.exe : fatal error LNK1120: 2 unresolved externals

-----------------------------------------------------------------------------------------------------------------

PROGRAM HELLO
    INTEGER NTHREADS, TID, OMP_GET_NUM_THREADS, OMP_GET_THREAD_NUM
! FORKA TEAM OF THREADS WITH EACH THREAD HAVING A PRIVATE TID VARIABLE
!$OMP PARALLEL PRIVATE(TID)

    ! OBTAIN AND PRINT THREAD ID
      TID = OMP_GET_THREAD_NUM()
      PRINT*, 'HELLO TO WORLD FROM THREAD = ', TID
      
    ! ONLY MASTER THREAD DOES THIS 
      IF(TID .EQ. 0) THEN
          NTHREADS = OMP_GET_NUM_THREADS()
          PRINT*, 'NUMBER OF THREADS = ', NTHREADS
      END IF
      
    ! ALL THREADS JOIN MASTER THREAD AND DISBAND
!$OMP END PARALLEL
END PROGRAM HELLO

I get the error: "Intel Software Setup Assistant has stopped working" in VS2017.

I am looking over a program written by someone else who did not believe in comments.  Delimiter highlighting is one of the useful tools aiding my comprehension and it works for most routines.   However, there is one where it does not.  I am using VS 2010 with Visual Composer XE 2012, SP1.  What sort of features of coding would make this fail.   I hasten to add that the routine compiles without complaining messages.  And the author did believe in indenting block levels.  I can't see anything wrong with his source code or the VS settings (which would have affected all routines).

However, I would like to know what can cause the delimiter highlighting to go off for the source code in a single routine.  I am hoping this is a fairly common and well understood phenomenon.  It need be, I can furnish the example.

Hello,

I'm somewhat new to Fortran and I had several questions. I'm currently trying to integrate a generated Fortran codebase to operate off a segment of memory passed to it from a C++ environment. One of my goals is to make as little change to the Fortran codebase as possible. I've been able to get several small scale examples of this method working fine with the C_PTR type with a derived type and also passing a byte array, but the problems arise with the compile times once I use the full size of the memory to be shared. The amount of memory I'm trying to share is about 15MB in size with about 800,000 variables of different types mapped against it. I'm pretty sure my approach of mapping these variables to be compatible with the generated codebase is the cause of the long compile times which last for days. I also imagine I'm not using the best practices for this problem.

For my first method, I created a large derived type containing all the variables that is passed through an exposed library function into the Fortran library from an identically defined struct in the C++ environment. To make that derived type compatible with the generated Fortran codebase I created a file that is #include'd so that the preprocessor replaces variables names that are #define'd to refer to a member of the large shared derived type. This compilation lasts for days and I never saw it to completion.

For my second method I defined a large byte array that's defined in a module along with an equivalence statement for every variable contained in the library to be mapped against. I pass the byte array from C++ through an exposed library method, and then the passed array is copied to the global array, and once all operations are finished in that subroutine the global module array is copied back to the subroutine's passed array so that changes are reflected in the passed C++ byte array. This compilation also lasts days. I tried to reduce the compile times by using the multiprocess compiler option and breaking the array into 5 separate arrays but that doesn't seem to have much of an impact. I'm also concerned about the runtime efficiency of this method since every time interact with the Fortran library a large array copy takes place instead of operating off a reference to the memory in the previous method.

To reduce compilation times, mostly in the second method, I've tried using equivalence statements in the Fortran source files only for the variables contained but this isn't allowed due to restrictions on using equivalence outside of the global array module definition. To get around that I've tried defining the passed array as COMMON but it seems like using common on subroutine arguments isn't allowed either. I could define the define a common array which is used in every source file, with equivalence statements only as needed, but I would still have to copy that array back and forth like described earlier, which worries me.

There might be an obvious solution to all this, but I am pretty new and some of the documentation/examples relating to this use case are a little sparse. I can provide some example code to show what I'm trying to do at a small scale if that might help with any suggestions.

Thanks,

David

I have some old F77 code (nleq1, horrible-looking but very effective) that I am using in F90 programs.  Currently I'm keeping the files separate, with a F90 file that defines a module, and several F77 files (*.f), one of which USEs the module.  It's all a bit messy.  I'm wondering if there is a way to collect the *.f files together in a module, and/or can a F90 file contain both free-form and fixed-form procedures.

This is more an observation than a question, but there is an implicit question.

I have a subroutine subx that includes

real(8) :: rtol = 1.0e-5

In this subroutine another subroutine suby is called with rtol one of the arguments.  Apparently this other subroutine changes rtol.  In IVF the behaviour is as I expected: in every call to subx the value of rtol passed to suby is 1.0e-5.  But when the program is built with gfortran there is an error, since the value of rtol in subx changes with each call (because it is changed by suby).  For gfortran it was necessary to add this line

rtol = 1.0e-5

before the call to suby.  Which behaviour is consistent with the standard?  I often assume the IVF behaviour.

The following code compiles but crashes with a stack overflow on entry in the parallel region when compiled with OpenMP. I played with stack settings, but to no avail. Removing the block construct leads to expected results, as do other trivial changes to the program.

module compute
    implicit none
    integer             :: nth, ny
    integer, parameter  :: nsim=20
    real, allocatable   :: Ys(:,:)

    contains

    subroutine prep
        integer :: l
        real    :: Y(ny),th(nth)

!$omp parallel do private(Y)
        do l=1,nsim
            y=0
        enddo
        print *,"done"

        block
            do l=1,10
                Y=5
                th=0
            enddo
        end block

    end subroutine

end module


program mfort
    use compute

    implicit none

    nth=5; ny=8;
    allocate(Ys(ny,nsim))
    print *,"hello"
    call prep

end program

Hi everyone,

I'm using ifort 17.0.2 on the command line (via nmake) to compile a Fortran DLL library and executable.

One problem I'm having is the issue of unit numbers being distinct in the DLL and executable.  I've read all the posts I could find on this and the solution was to make sure that the DLL and the executable link to the same run-time library (e.g., both have /MD switch).  This doesn't work for me though.  Is there anything else that needs to be done?  The library and program run fine if I don't do any input/output.

--Elizabeth

Who or what is behind warnings such as "#5436: Overlapping storage initializations encountered with .T1386__dv_template_V$749", and why are they/it picking mercilessly on my deferred length allocatable character variables?

I am developing a C++ application using Microsoft Visual C++ in Microsoft Visual Studio 2015. From my C++ application, I need to call some numerical software written in Fortran. This software is free and publicly accessible, and full Fortran source code is available for it. I am considering purchasing the Intel Fortran Compiler to compile the Fortran source code. I'd like to produce a static library, which I will then link against my Visual C++ application.

My question is: Will I be able to call the Fortran library (compiled with the Intel Fortran Compiler) from Microsoft Visual C++ ?

I know that if I was using Intel's C++ compiler that I could then link against Intel Fortran-compiled code. However, it is not practical for me to switch to the Intel C++ compiler. Can I continue using Microsoft Visual C++, and link against a Fortran static library produced using the Intel Fortran Compiler? Will this solution require me to distribute (to my customers) some run-time DLLs from Intel Fortran?

Thank you. 

This is kind of a newbie question, but I'm not very familiar with setting up the coding environment and searching google haven't given me clear answers, so hopefully someone here can help me.

The intel fortran compiler I have been using was finally upgraded, but I also need the MKL and OpenMp dll's to be upgraded with it.

Should this have happened automatically when the new version was installed?

Or is this something separate that I need to download and put in the redistributable folder?

Or is this something that we somehow build with the new version of the intel compiler?   

In simpler words... How do I get the latest version of libiomp5md.dll and other similar dll's?

Hi All, I'm trying to build a WIN32 (32-bit) DLL but it won't work from excel and I'm getting errors from DependencyWalker that different CPU types are used, DW is saying there are three LIBxxx.DLL files that are x64 whilst all others are x86. I've checked the Compilers tab under \tools\options\ and all options seem OK, I've also tried Resetting them, but to no avail. I'm using compiler Compiler 17.0.4.210 [IA-32] and Visual Studio13

Can anyone suggest why my WIN32 DLL is linked to the wrong redistributable (x64) DLLS (LIBxxx.DLL)?

regards

karl skinner