I am experimenting with recursive subroutines.  If I compile and run a simple program, where a recursive subroutine calls itself many times, it crashes with a stack overflow.  I have figured out that to fix this, I have to set the Stack Reserve Size to a large value.  Is there a way to disable the stack usage?  I have tried using /heap-arrays0 option, but it did not help.

If I can't disable the stack and I want to use recursive subroutines, do you think I should just set the Stack Reserve Size to a maximum of 1 GB to prevent any stack overflows?

Hi,

I'm supporting a legacy fortran program. Everything runs fine except for a few clients who get the following message:

cannot open message catalogus "\1043\libguide40ui.dll"

I'm not new to programming, but rather new to fortran and read something about this library on this forum, but I don't understand what I should do to get rid op the issue as easy as possible. Should copying libguide40ui.dll to the program directory solve the problem, and is that a good solution ?

If no ... what should I do (simple step by step explanation would be welcome)

Leon

I constructed my RC file in Visual Studio 2013, but I developed my .f90 files outside of VS once they were created in VS as a fram for an SDI file. I am trying to create something like the Angle project with a dialog as the main window and perform graphics in the SDI framework. My dialog styles are exactly as the main dialog in Angle. The RC compiles my rc-file with no warnings or errors. I'm using:

Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.0.110 Build 20150815
My build gives no warnings nor errors as:

g:\Desktop\Pearson>rc Pearson.rc
Microsoft (R) Windows (R) Resource Compiler Version 6.3.9600.17298
Copyright (C) Microsoft Corporation.  All rights reserved.
g:\Desktop\Pearson>rem ifort /nologo /c PearsonGlobals.f90
g:\Desktop\Pearson>ifort /nologo /WinApp Pearson.f90 MyLib.Lib Pearson.res

My code to startup the dialog looks like:

     bret = DlgInit( IDD_PMAIN, gDlg)
     If (bret == FALSE) Then
        ret = MessageBox(0, "DlgInit failed to launch IDD_PMAIN"C, "SetUpMyDlg"C, MB_OK)
        Call PostQuitMessage(999)
        return
     End If
     hDlg = gDlg%HWND
     hWndDlg = hDlg
     bret = DlgSetSub(gdlg, IDD_PMAIN, WinDlgSub)
     type *, 'SetUpMyDlg:: DlgSetSub(IDD_PMAIN) RC = ', bret
     bret = DlgSetSub(gDlg, IDC_FIT, DlgChanged)
     type *, 'SetUpMyDlg:: DlgSetSub(IDC_FIT) RC = ', bret
     bret = DlgSetSub(gDlg, IDC_SAMP, DlgChanged)
     type *, 'SetUpMyDlg:: DlgSetSub(IDC_SAMP) RC = ', bret
     bret = DlgSetSub (gDlg, IDC_PCTYPE, OnSpinEdit, DLG_LOSEFOCUS)
     type *, 'SetUpMyDlg:: DlgSetSub(IDC_IDC_PCTYPE) RC = ', bret
     bret = DlgModeless(gDlg, nCmdShow)
     type *, 'SetUpMyDlg:: DlgModeless RC = ', bret
     If (bret == FALSE) Then
        ret = MessageBox(0, "DlgModeless failed for IDD_PMAIN"C, "SetUpMyDlg"C, MB_OK)
        Call PostQuitMessage(998)
        return
     End If

My debug produces:

 SetUpMyDlg:: DlgSetSub(IDD_PMAIN) RC =  T
 SetUpMyDlg:: DlgSetSub(IDC_FIT) RC =  T
 SetUpMyDlg:: DlgSetSub(IDC_SAMP) RC =  T
 SetUpMyDlg:: DlgSetSub(IDM_EXIT) RC =  F
 SetUpMyDlg:: DlgSetSub(IDC_IDC_PCTYPE) RC =  T
 SetUpMyDlg:: DlgModeless RC =  F

And then I get the MessageBox notice. Can anyone help me?

Thanks, Brooks

Dear Sir(s),

I have been using Intel® Composer XE for Windows* (formerly Intel® Compiler Suite Professional Edition for Windows*).

My college has used a newer version of your compiler, and we worked on the same code. When I got the code back from him this time, I can compile it successfully with release mode, but failed with the debug mode.

The first error is:

Error    1     error #6405: The same named entity from different modules and/or program units cannot be referenced.   [FINDSTRG]    d:\MIN3P_THCm\min3p_thcm_v396Recheck\src\icesheet\m_ice_sheet.F90    1224    

That’s however not the case, otherwise it will fail when compiled under release version.

The function findstrg is defined in the following subroutine, which has been applied over 400 times in the code without any problem before:

!c ----------------------------------------------------------------------

!c subroutine findstrg

!c -------------------

!c find text string in data file      

!c definition of variables:

!c

!c I --> on input   * arbitrary  - initialized  + entries expected

!c O --> on output  * arbitrary  - unaltered    + altered

!c                                                                    I O

!c passed:   integer*4:

!c           ----------

!c           itmp

!c

!c           logical:

!c           ---------

!c           found_subsection

!c

!c           character:

!c           ----------

!c           subsection

!c

!c common:   -

!c

!c local:    character:

!c           ----------

!c           string

!c ----------------------------------------------------------------------

      subroutine findstrg(subsection,itmp,found_subsection)

     implicit none

      character*72 subsection

      integer itmp

      logical found_subsection     

      character*72 string

!c  rewind input file

      rewind(itmp)

!c  search for test string in input file

      found_subsection = .false.

      do while (.not.found_subsection)

        read(itmp,*,end=999) string

        if (string.eq.subsection) then

          found_subsection = .true.

        end if

      end do

999   return

      end

When it is called in the following subroutine more than once, the error occurs:

!%************************************************************

subroutine read_ice_sheet_block_ice_sheet  &

  (this, &

   idat, &

   istemp, &

   icetimeline, &

   iserror)

implicit none

external findstrg

!% Maximum pressure update in each timestep

subsection = 'maximum ice loading boundary pressure update'

call findstrg(subsection,idat,found)

if (found) then

  read(idat,*,err=10) max_update_pw

  b_check_update_pw = .true.

else

  b_check_update_pw = .false.

end if

!% Maximum pressure update in each timestep

subsection = 'maximum ice loading internal pressure update'

call findstrg(subsection,idat,found)

if (found) then

  read(idat,*,err=10) max_update_pice

  b_check_update_pice = .true.

else

  b_check_update_pice = .false.

end if

end

I tried also using interface to replace the 'external findstrg' before the subroutine including the code 'call findstrg' as suggested in the previous forum discussions, it failed with the same error.

Would you please help?

Thanks,

David

I want to get LAPACK running with Intel Fortran using Visual Studio to develop fortran applications. I am unable to link to LAPACK libraries when I write Fortran code. I wrote a simple progran that calls the LAPACK routine dgemsv, and I have used the project properties to specify lapack libraries locations and lib names. I get error 11018 twice and fatal link error LNK1181. I searched the web for a solution, and found that I should run CMAKE. This software gives error "Package 'IFLangServicePackage' failed to load". These cryptic solutions with no one to help when there are errors are useless. Could someone please tell me how to link to the lapack libraries using intel fortran in visual studio 2013?

Hi,

I am an old FORTRAN developper working nowadays with young engineers. We all have laptops but, for some ununderstandable safety reason, Win7 goes to sleep mode after 15 minutes and we have no access to this parameter in 'configuration panel'. I am working on a 'long' app about 6 hours. When I work on the PC, it's ok but I can't go to eat or, worst, I can't test a new version during night.

In the app, I tried to create 'dummy' files on the HDD every now and then but in vain.

Is there a way, from within a Fortran app running in console mode, to prevent Win7 to go sleeping ?

Thanks in advance

Jean

PS English is not my natural language ! I am 'new' to Intel Fortran.

PS I was very pleased to see on this forum that Fortran was well alived !

Is it possible to downgrade license from 16v to 12v? In order to compile fortran files, which are verified for 12.1.5 version?

Hello,

I am trying to compile a main program (replica2.f90) with 5 INCLUDE files. Here are the commands I tried:

ifort -cpp mc_st.f90 molecules.f90 orientation.f90 forward_n1n1p1_rep.f90 reverse_n1n1p1_rep.f90
ifort replica2.f90

mc_st.f90 is my global variables file. The others are parts of separated subroutines called by the main program. I have successfully run this on my laptop with Microsoft Visual Studio, but it took forever to complete. I am trying to use a supercomputer to compile my code instead, but apparently it didn't work. Here are the error messages:

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

mc_st.f90, molecules.f90, orientation.f90, forward_n1n1p1_rep.f90, reverse_n1n1p1_rep.f90: error #5082: Syntax error, found END-OF-FILE when expecting one of: <LABEL> <END-OF-STATEMENT> ; BLOCK BLOCKDATA PROGRAM MODULE TYPE BYTE CHARACTER ...

molecules.f90(32): error #6410: This name has not been declared as an array or a function.   [NB]
   Nb(i,1)     =  num_mol(i)*l_side*l_side ! number of molecules of H

orientation.f90(11): error #6353: A RETURN statement is invalid in the main program.
   RETURN      

orientation.f90(13): warning #6043: This Hollerith or character constant is too long and cannot be used in the current numeric context.   ['Silica']
   ELSE IF (Molecule_type(new_type).EQ.'Silica') THEN

orientation.f90(1056): error #6353: A RETURN statement is invalid in the main program.
     IF (t.LT.50.0) RETURN  

orientation.f90(2): error #6591: An automatic object is invalid in a main program.   [E_NEW]
DIMENSION :: e_new(3,natoms),q_new(3,ncgs),orient1(3,natoms),orient2(3,ncgs),di_ang_new(2),random(3)

orientation.f90(2): error #6219: A specification expression object must be a dummy argument, a COMMON block object, or an object accessible through host or use association   [NATOMS]
DIMENSION :: e_new(3,natoms),q_new(3,ncgs),orient1(3,natoms),orient2(3,ncgs),di_ang_new(2),random(3)

........[Many other similar errors].......

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

It appears that:

1. The structures of all the INCLUDE files are wrong (I know for module, it starts with MODULE <name> and ends with END MODULE <name>, but I don't know the format for INCLUDE file).

2. My main program couldn't include the global variables file

3. I don't even know what "error #6591: An automatic object is invalid in a main program." means.

Could someone please help me with a correct (and preferably optimized) ifort command for my codes? I am really new to this.

Thank you!

Steve (or whoever gets this), we recently switched compilers from 15.0.3 to 16.0.1 and are now experiencing a significant (catastrophic) increase in compile time.  On a linux box, compile times went from 5 minutes to 40-50 minutes.  Are there any other reports of this?  I have given you our entire code in the past when we experienced this with 13 or 14 version compiler a few years ago (~4 years I think). Might be worthwhile to do something similar here.  Just wanted to get your take on it.

On a side note, we also see a few "*** glibc detected *** /usr/local/intel/compilers_and_libraries_2016.1.150/linux/bin/intel64/fortcom: free(): invalid pointer: 0x000000000469a060 ***" during compilation (and with version 15 compiler as well) but the code operation seems unaffected.

My understanding is that when I get an out-of-range subscript it is supposed to put me in the routine

where that occurred so I can look at variables in the same routine.

What is actually does: is put the little blue arrow in a place that has NOTHING to do with the routine,

so I cannot look at any variable in the routine. The call stack is completely wrong as well, so I cant use that either.

so - - I have to go back and insert a breakpoint(F9) near where the problem occurred, and/or stick in print statements, etc.

and run it again.

The text in the output is correct, BTW, it does tell you what line number, etc.

Ths problem seems to come up when the breakpoint is within an internal routine, i.e. one that comes after a CONTAINS statement.

Its a minor annoyance, but still I cant help but wonder why they did not test this ?? VS has been around for a long time, right ?

I got a program to compile and sent the EXE to a friend and when he tried to run it, an error pops up saying libifcoremd.dll is missing and to try reinstalling. I had a similar problem a while back and it turned out I had to select a different library.  I'll try to put in a screen shot of the options.

Any ideas on which of the library options would be best when sending an EXE to someone?  He said something about he statically links their windows programs.

I have installed Intel(R) Cluster Studio XE 2013 SP1 Update 1 for a single node. It is also showing that successfully installed. But when I type "ifort" in the terminal, I get "command not found". Can you please tell me it is an issue related to installation or something else.

Greetings to all,

I'm a Msc student,

I have a fortran subroutine to compute the non linear behavior of a material, however it must be changed a little in order to be compatible with the UMAT.  but i don't have enough knowledge in fortran programing

Can anyone help me with this.

The subroutine file is attached.

Thank you 

IVF 16 compiles the following code with 0 errors, 0 warnings,

program main
    implicit none
      integer:: i
      real, allocatable:: a(:)
      real:: c(5) = [(i, i = 1,5)]
     a = c     !   allocation F03   
     print *, '  array a has ', size(a), ' elements:'
     print *, a

end program main

The output is that the array has 0 elements and of course no values. Apparently the F03 style allocation in the assignment statement a=c does not work as it should.

The program runs correctly with 2 other compilers.

Is the F03 allocation feature not implemented in IVF 16?

BR

Dimitris

Hi Everyone

I wonder whether it is possible to assign variable to values in different subroutines. for example, 

subroutine a

b=5

a=b+c

call cvalue

end subroutine a

subroutine cvalue

c=2

end subroutine cvalue

Please help.

Is the following simple code snippet standard-conforming?  The code compiles with no errors or warnings with the latest Intel Fortran 16.0 compiler, update 1.  Note the missing proc_language_binding_spec of bind(C) on the procedure target which, to me, appears like a difference in characteristics of the object and the target.  Is this something a coder can expect from the compiler to get flagged as an error?

Thanks,

module m

   implicit none

   abstract interface

      subroutine Ifoo() bind(C)

      end subroutine Ifoo

   end interface

   procedure(Ifoo), pointer :: foo => subfoo

contains

   subroutine subfoo()  !.. Note the missing proc_language_binding_spec of bind(C)

   end subroutine subfoo

end module m

Listed below is an extract from Fortran 2008 standard document (WD 1539-1 J3/10-007r1 dated 2010-11-24): 

7.2.2.4 Procedure pointer assignment
..
3 If the pointer object has an explicit interface, its characteristics shall
  be the same as the pointer target except that the pointer target may be
  pure even if the pointer object is not pure and the pointer target may be an
  elemental intrinsic procedure even if the pointer object is not elemental. 

Hi,

I am using fortran for coding. Now I am going to read more than 1000 data files separately, from the data file folder D\Datas\fortran

And the data filenames are like:

Gstep00001.dat  Gstep00002.dat  ... Gstep01230.dat

and the contents are like:

    -0.0004349421733      1.0583843781537
    -0.0004059937166      1.0583825316509
    -0.0003770452599      1.0583806851481
    -0.0003480968032      1.0583788386453
    -0.0003191483465      1.0583769921425
    -0.0002901998898      1.0583751456397
    -0.0002612514331      1.0583732991369
    -0.0002323029764      1.0583714526341
    -0.0002033545197      1.0583696061313
    -0.0001744060630      1.0583677596285

....

....

So how to accomplish this in fortran, please? Waiting for your help, thanks!

Sinserely

Ren

Hi,

Before deploying the latest version of the compiler (XE 2016), I was trying to compile some existing code and I got an ICE in every routine that uses the associate construct. The construct is used to associate a local variable to a derived type that is allocated through the malloc function. Wou will find attached a simple Visual Fortran project that compiles and runs fine with the compiler version we are currently using (Intel(R) Visual Fortran Compiler XE 14.0.0.103 [IA-32]) but generates an ICE with version 16.0 as shown below:

------ Rebuild All started: Project: associate_ICE, Configuration: Debug Win32 ------
Deleting intermediate files and output files for project 'associate_ICE', configuration 'Debug|Win32'.
Compiling with Intel(R) Visual Fortran Compiler 16.0 [IA-32]...
CmpdDef.f90
V:\Tests\associate_ICE\associate_ICE\CmpdDef.f90(6): warning #6379: The structure contains one or more misaligned fields.   [TTCORRELATION]
Mod_PropData.f90
associate_ICE.f90
ResetTPropData.for
0_1855
V:\Tests\associate_ICE\associate_ICE\ResetTPropData.for(11): catastrophic error: **Internal compiler error: internal abort** 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 V:\Tests\associate_ICE\associate_ICE\ResetTPropData.for (code 1)

Build log written to  "file://V:\Tests\associate_ICE\associate_ICE\Debug\BuildLog.htm"
associate_ICE - 1 error(s), 1 warning(s)
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

I have been able to mangage the situation by removing the use of the associate construct but I would like to know if it's a compiler bug or if my way of using the construct is wrong (but not detected in previous versions).

Best regards,

Hello,

I believe the following code produces an incorrect result:

program main
!$ use omp_lib
  integer a,i
  !$omp parallel
  !$omp master
  do i=1,10
  !$omp task firstprivate(i) if(i>5) depend(inout:a)
    write(*,*) '--->',i
  !$omp end task
  enddo
  !$omp end master
  !$omp end parallel
end program

What happens is the undeferred tasks (those for which the IF clause evaluates to false) are not executed at all, i.e., the code prints:

 --->           6
 --->           7
 --->           8
 --->           9
 --->          10

The problem disappears if either the IF or DEPEND clause are removed.

I have observed this problem with ifort 15.0.2 and 16.0.1. gfortran 4.9.3 produces the correct result.

Can the developers confirm this is a bug?

Thanks,

Theo

My build looks like:

G:\Desktop\Pearson>build

G:\Desktop\Pearson>rem Build script for Pearson
G:\Desktop\Pearson>deftofd resource.h resource.fd
G:\Desktop\Pearson>rc Pearson.rc
Microsoft (R) Windows (R) Resource Compiler Version 6.3.9600.17298
Copyright (C) Microsoft Corporation.  All rights reserved.

G:\Desktop\Pearson>call cf pearsonglobals
G:\Desktop\Pearson>iFort /nologo -Od /traceback /c pearsonglobals.f90
G:\Desktop\Pearson>lib /nologo MyLib.lib pearsonglobals.obj
Replacing pearsonglobals.obj

G:\Desktop\Pearson>ifort /nologo /WinApp Pearson.f90 MyLib.Lib Pearson.res
MyLib.Lib(purge.obj) : error LNK2019: unresolved external symbol RANFGET referenced in function PURGE
MyLib.Lib(purge.obj) : error LNK2019: unresolved external symbol RANFPUT referenced in function PURGE
Pearson.exe : fatal error LNK1120: 2 unresolved externals

I don't know why the link step does not pick up MyLib.lib which is local to all the source codes. Below, I've had lib list all of its entries. The ranf.obj has 3 routines in it and it is encompassed by a module I call Random. The invoking routine, Purge, has a use statement invoking random. What am I doing wrong?

Thanks,
Brooks V

G:\Desktop\Pearson>lib /list mylib.lib
Microsoft (R) Library Manager Version 12.00.31101.0
Copyright (C) Microsoft Corporation.  All rights reserved.

pearsonglobals.obj
purge.obj
TypeVII.obj
TypeV.obj
TypeIII.obj
TypeI.obj
LnGamma.obj
GetK.obj
Howe.obj
Van.obj
dographs.obj
dohisto.obj
getrs.obj
Horn.obj
zData.obj
Integrate.obj
TypeII.obj
TypeIV.obj
TypeVI.obj
TypeVIII.obj
ranf.obj