I have a strange problem that just started popping up with a program I have been marketing for ten years now. It seems to be related to Win-7, but I cannot reproduce it on any of my own computers. The program installs and runs, but after roughly ten seconds, it shuts down on its own. I'm thinking maybe an anti-virus program, but why would it wait until the program is running to shut it down? I'm running VS 10.0.40219.1 SP1Rel and .NET 4.5.50938 SP1Rel. If anybody has any ideas on what to look for, I would sure appreciate your input.

These free technical webinars cover tips and techniques that will help sharpen your development skills to create faster, more reliable applications. Technical experts will cover topics ranging from vectorization, code migration, code optimization, using advanced threading techniques (e.g., OpenMP 4.0, Intel® Cilk™ Plus, Intel® TBB), and error checking. Bring programming questions to the live session for our technical experts to answer. A replay of each webinar will be available shortly after the live session so you can share with those unable to attend the live session.

See http://software.intel.com/en-us/articles/intel-software-tools-technical-... for more information and to register.

I've been having difficulty again on Windows 8.1.  ifort setup with Visual Studio 2012 Pro for X64, using command prompt, doesn't retain the path to CL after reboot and so refused to perform a link.  I can complete a build combining ICL and ifort by building .obj in the VS2012 cmd prompt and switching over to VS2010 shell prompt to link (I didn't ask for the VS2010 shell setup).

I can run vcvarsall.bat to get 32-bit CL on the path, but don't know an equivalent incantation to get the 64-bit CL.

This may be more of a Microsoft than an Intel tools issue, but surely there is a way to write a script which will put the Microsoft tools required by Intel compilers back on PATH.

I've been through the laborious route of removing all Intel and visual studio tools and re-installing from scratch (about 3 hours when not attempting the on-line installation), but it doesn't reliably fix this.

I attempted to file an IPS support issue but the site isn't responding.

After moving from CVF6.6 to IVF XE 12.0 update 4, I obtained the error message

Compilation aborted (code 1)

Is there any documentation on the possible sources of this error? (which I guess there are quite a few). I wonder why is the error message not any more specific.

*****************************************************************

The way I proceeded to find the culprit was:

1- Comment all lines of code, except:

* program start / end

* subroutine protocols (subroutine x(var1, ...))

* subroutine end

* implicit none

* variables declarations

2- Incrementally uncomment small pieces of code.

I isolated the issue. I was passing a string constant as an argument for a subroutine call. The corresponding parameter of the subroutine was

character*200 mystr

I replaced the string constant in the caller line of code by a variable name. That variable was also defined as character*200. That solved the problem.

As mentioned by Steve Lionel the cause of the error may vary.

"Find all reference" is not working in Visual Studio 2013. The Fortran compiler version is 2013 SP1 Update2 and the OS is Windows 8.1 64bit.

Hi IVF,

A problem is found that the value of a variable declared in one subroutine will be changed by the IVF compiler after the code direction is switched from another subroutines. I made a test to show the problem with a test code as shown below.

====================================test code=============================================

program main

    implicit double precision(A-H,O-Z)

    call entry1

    call sub2

    call entry2

    write(*,*) "Test end."

end

subroutine sub1

    implicit double precision(A-H, O-Z)

    entry entry1

    Q=0.05

    write(*,*) "Before switching from entry1 to sub2, Q: ", Q

    pause

    return

    

    entry entry2

    write(*,*) "After the code switching from the sub2 to the sub1, Q:", Q

    pause

    return

end subroutine sub1

subroutine sub2

implicit double precision(A-H,O-Z)

!!............. (no declaration and precess is related to the variable Q)

return

end subroutine sub2

====================================test code=============================================

A variable Q with an initial value 0.05 is declared in the sub1, while no process is applied in the sub2.

Main program will enter the sub1 through the entry1, return to the main, enter the sub2, return to the main, and then enter the sub1 through the entry2. The values of Q in the sub1 at the entry1 and entry2 are outputted on the monitor.

The result of the test is shown in the following figure. The value of Q before switching to the sub2 is the same as the declaration, while it changed to an extremely large negative value automatically when the code get back to the sub1 from the sub2.

The test code can work normally (Q values are the same) with the old Fortran compiler (e.g. Digital VIsual Fortran) so I think the problem would be due to the IVF.



Any suggestion?   

v[[{"fid":"315938","view_mode":"default","fields":{"format":"default","field_file_image_alt_text[und][0][value]":"","field_file_image_title_text[und][0][value]":"variable Q is canged by the switching between subrutines","field_tags[und]":""},"type":"media","attributes":{"title":"variable Q is canged by the switching between subrutines","height":116,"width":644,"class":"media-element file-default"}}]]

I currently have a 32 bit DLL which opens a modeless dialog box.  I want to recompile it as a 64 bit DLL but I get errors at runtime (First-chance exception at 0x772a7eb8 (ntdll.dll) in Dialog_Dll_Exe_New.exe: 0xC0000005: Access violation reading location 0xffffffffef4a0000) and the dialog box fails on initialization.  Bare-bones code is below.  Any help would be appreciated.  Thanks, Steve

  integer(4) function DllMain (hInst, ul_reason_being_called, lpReserved)
  !DEC$ IF DEFINED(_X86_)
  !DEC$ ATTRIBUTES STDCALL, ALIAS : '_DllMain@12' :: DllMain
  !DEC$ ELSE
  !DEC$ ATTRIBUTES STDCALL, ALIAS : 'DllMain' :: DllMain
  !DEC$ ENDIF
    use dll_globals
    integer(handle) hInst
    integer(dword) ul_reason_being_called
    integer(lpvoid) lpReserved
    ghInst =  hInst
    DllMain = 1
    return
  end

module dll_globals
    use iflogm
    use ifwin
    integer(handle) ghInst      ! Global instance handle for Dialog Box
    type (dialog) gdlg       ! Defines a dialog data type
  end module dll_globals

subroutine dialog_dll_64 (mode) ! DLL Entry point

  ! Expose subroutine dialog_dll_64 to users of this DLL
  !
    !DEC$ ATTRIBUTES DLLEXPORT::dialog_dll_64
    !DEC$ ATTRIBUTES STDCALL, ALIAS:'dialog_dll_64' :: dialog_dll_64
    
  ! Variables
    USE IFLOGM
    USE DLL_GLOBALS
    USE USER32
    USE KERNEL32
    INCLUDE 'resource.fd'    EXTERNAL WinDialogQuit
    INTEGER :: MODE
    LOGICAL :: lret
    CHARACTER (LEN=40) :: VERSION, TITLE
    DATA VERSION / '5.0'/
!    
! Initializes dialog box - sets dialog box name to a Type (dialog) object called "gdlg"
!
        lret = DlgInitWithResourceHandle(IDD_DIALOG2, ghInst, gdlg)
        title = 'LAM '//trim (version) // ' - TIREM 3.14'        CALL DLGSETTITLE (gdlg, title) 
        lret = dlgset(gdlg, IDC_STATIC1, 'Initializing LAM - TIREM')
        lret = DlgSetSub(gdlg, IDCANCEL, WinDialogQuit)
!    
! Show dialog box and declare it a modeless dialog
!
        lret = DlgModeless(gdlg, SW_SHOWNORMAL)       
!
!  Close dialog window
        call dlgexit(gdlg)
        call DlgUninit(gdlg)
!
    return

end subroutine dialog_dll_64

!****************************************************************************
!  FUNCTION: WinDialogQuit ( dlg, id, callbacktype )
!  PURPOSE:  Dialog box callback for initialization and destroy
!****************************************************************************

SUBROUTINE WinDialogQuit( dlg, id, callbacktype )
!DEC$ ATTRIBUTES DEFAULT :: WinDialogQuit

  use user32
  use iflogm

  implicit none

  type (dialog) dlg
  integer id, callbacktype
  if (callbacktype == dlg_clicked) then
    call PostQuitMessage(0)
    call dlgexit(dlg)
  endif
  END SUBROUTINE WinDialogQuit

    program Dialog_64_Exe  ! Main program which calls the DLL

  !DEC$ ATTRIBUTES DLLIMPORT::dialog_dll_64
  !DEC$ ATTRIBUTES STDCALL, ALIAS:'dialog_dll_64' :: dialog_dll_64

    use iflogm
    use dll_globals
    implicit none
    integer :: mode
    mode = 1
    call dialog_dll_64 (mode)
    stop
    end program Dialog_64_Exe

Dialog Resource file:

//{{NO_DEPENDENCIES}}
// Microsoft Visual C++ generated include file.
// Used by Resource1.rc
//
#define IDD_DIALOG2                     103

// Next default values for new objects
// 
#ifdef APSTUDIO_INVOKED
#ifndef APSTUDIO_READONLY_SYMBOLS
#define _APS_NEXT_RESOURCE_VALUE        104
#define _APS_NEXT_COMMAND_VALUE         40001
#define _APS_NEXT_CONTROL_VALUE         1003
#define _APS_NEXT_SYMED_VALUE           101
#endif
#endif

Hi, I got trouble when debugging. 

The code is finished in CVF. When I run it in IVF (0 error), it breaks.

The picture is what happened. However I have no idea how to solve it.

Thanks![[{"fid":"316843","view_mode":"default","fields":{"format":"default","field_file_image_alt_text[und][0][value]":"","field_file_image_title_text[und][0][value]":"","field_tags[und]":""},"type":"media","attributes":{"height":1040,"width":1918,"class":"media-element file-default"}}]]

When writing records to a direct access file I am finding that the Intel Fortran compiler is much slower than my 17 year old Watcom Fortran compiler running exactly the same code. In fact the Intel compiler is around 10 times slower!! This doesn't seem right to me. Can anyone see what I am doing wrong in the code segment below? Note that if CASES=1970 and BMS=5167, it is writing over 10 million records and this is taking around 8 minutes on my I7 laptop, whereas the ancient Watcom compiler does it in less than a minute.



You can see that I have a PeekMessage statement in the loop so that it can process Windows messages, however I am finding that the speed is the same with or without it.



Help!

      INTEGER*4  RCD,CASES,BMS,CNUM,NMP,MEM,IO

      STRUCTURE /MACTIONS/

         INTEGER*2  NTCN,BKL

         REAL*8     FM(12),Extra(6),Diff(6)

      END STRUCTURE

      RECORD /MACTIONS/ MACT(BMS,CASES)

      TYPE(T_MSG)    Msg

      OPEN (MALUN,FILE='FRED.DAT'

     c        ,STATUS='NEW'

     c        ,ACCESS='DIRECT'

     c          ,FORM='UNFORMATTED'

     c        ,ACTION='READWRITE'

     c          ,RECL=200

     c        ,IOSTAT=IO)

      RCD=0

      DO CNUM=1,CASES

         PeekMessage (Msg,0,0,0,PM_REMOVE)

         DO NMP=1,BMS

            RCD=RCD+1

            WRITE (MALUN,REC=RCD,IOSTAT=IO) NMP

     c      ,(MACT(NMP,CNUM).FM(I),I=1,12)

     c      ,MACT(NMP,CNUM).NTCN,MACT(NMP,CNUM).BKL

     c      ,(MACT(NMP,CNUM).Extra(I),I=1,6)

     c      ,(MACT(NMP,CNUM).Diff(I),I=1,6)

         ENDDO

      ENDDO

      CLOSE (MALUN)

Does a DLL compiled with IVF Composer XE 2013 work on Win Azure cloud platform?

    Hello

           I am trying to build a fortran project with a 'c' library named PETSc. During compilation some functions are missing, and they appear as    unresolved externals after linking. It seems that the problem is the underscore prefix inside the 'c' funtions. How can I turn off that option to avoid these errors?

   thanks

Hi,

I have a console program that uses command line arguments like

app.exe  inp1.txt inp2.txt  out1.txt  out2.bmp

and I use 

call GETARG(3,fln1)  

call GETARG(4,fln2) 

to supply the filenames for the out1.txt and out2.bmp

For reading these input files I have 

 OPEN(UNIT = 101, FILE = '', STATUS = 'OLD', IOSTAT = IERR)

and the File =  '' takes in inp1.txt and a separate one for inp2.txt

  The issue is during debugging (using command arguments) it returns error in opening input file and I have to physically replace it with the filename

   OPEN(UNIT = 101, FILE = 'inp1.txt', STATUS = 'OLD', IOSTAT = IERR)

Why is this so. The compiled executable runs fine but during debugging I have to hardcode it in. The reason for the input file name to be different each time is this is run on a webinterface with multiple users possibly running the same application simultaneously and hence each user has a separate input and output filename

Thanks for any help

Sumit

   Hello

    I am trying to build PETSc inside a fortran project. And after hard work I got this:

Deleting intermediate files and output files for project 'PETScFORTRAN', configuration 'Debug|x64'.
Compiling with Intel(R) Visual Fortran Compiler XE 14.0.2.176 [Intel(R) 64]...
ifort /nologo /debug:full /Od /fpp /I"C:\Program Files\PETSc for Windows\PETSc\include" /I"C:\Program Files\PETSc for Windows\PETSc\include\finclude" /I"C:\Program Files\PETSc for Windows\PETSc\include\finclude\ftn-auto" /I"C:\Program Files\PETSc for Windows\PETSc\include\finclude\ftn-custom" /I"C:\Program Files\PETSc for Windows\PETSc\c-debug_icl_mkl\include" /I"C:\Program Files\PETSc for Windows\PETSc\include\mpiuni" /DWINDOWS /warn:interfaces /module:"x64\Debug\\" /object:"x64\Debug\\" /Fd"x64\Debug\vc110.pdb" /traceback /check:bounds /check:stack /libs:static /threads /dbglibs /winapp /c /extfor:F /Qvc11 /Qlocation,link,"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\\bin\amd64""C:\Users\Pedro\Desktop\fortran_test\PETScFORTRAN\ex14f.F"
Linking...
Link /OUT:"x64\Debug\PETScFORTRAN.exe" /INCREMENTAL:NO /NOLOGO /LIBPATH:"C:\Program Files\PETSc for Windows\PETSc\c-opt_icl_mkl\lib" /LIBPATH:"C:\Program Files\Microsoft HPC Pack 2008 R2\Lib\amd64\\" /LIBPATH:"C:\Program Files\Microsoft MPI\Lib\amd64" /LIBPATH:"C:\Program Files\PETSc for Windows\lib\intel64" /LIBPATH:"c:\Program Files\PETSc for Windows\PETSc\externalpackages\libs\\" /NODEFAULTLIB:"LIBCMT.lib" /MANIFEST /MANIFESTFILE:"C:\Users\Pedro\Desktop\fortran_test\PETScFORTRAN\x64\Debug\PETScFORTRAN.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"C:\Users\Pedro\Desktop\fortran_test\PETScFORTRAN\x64\Debug\PETScFORTRAN.pdb" /SUBSYSTEM:CONSOLE /IMPLIB:"C:\Users\Pedro\Desktop\fortran_test\PETScFORTRAN\x64\Debug\PETScFORTRAN.lib" advapi32.lib libpetsc.lib mkl_intel_lp64_dll.lib mkl_intel_thread_dll.lib mkl_core_dll.lib libiomp5md.lib msmpi.lib msmpifmc.lib  "x64\Debug\ex14f.obj"
Link: executing 'link'
libifcoremt.lib(for_main.obj) : error LNK2019: unresolved external symbol __intel_new_feature_proc_init referenced in function main
x64\Debug\PETScFORTRAN.exe : fatal error LNK1120: 1 unresolved externals


PETScFORTRAN - 2 error(s), 0 warning(s)

How can this be fixed?

    Help

NOTE: this is a copy of the thread at the Linux forum.  My apologies to those who have seen it there - I'm posting it here with the hope of getting more comments and feedback and generating some discussion amongst the Windows users.

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

Fortran enthusiasts may have seen and/or be interested in the findings and observations in a recent open literature publication by Arabas, et al. at the Institute of Geophysics at the University of Warsaw. Here’s the link to this paper: http://arxiv.org/abs/1301.1334

It is very interesting to read Arabas et al. find “that C++11/Blitz++, Python/NumPy and Fortran 2008 provide comparable functionalities in terms of matching the blackboard abstractions within the program code. Taking into account solely the part of code representing particular formulæ (e.g. listings C.21, P.17, F.20 and equation 4) all three languages allow to match (or surpass) LATEX in its brevity of formula translation syntax. All three languages were shown to be capable of providing mechanisms to compactly represent such abstractions as: • loop-free array arithmetics; • definitions of functions returning array-valued expressions; • permutations of array indices allowing dimensionindependent definitions of unctions (see e.g. listings C.12 and C.13, P.10 and P.11, F.11 and F.12); • fractional indexing of arrays corresponding to employment of a staggered grid.”

The authors make pointed comments about some of the limitations they faced with Fortran, “Three issues specific to Fortran that resulted in employment of a more repetitive or cumbersome syntax than in C++ or Python were observed: • Fortran does not feature a mechanism allowing to reuse a single piece of code (algorithm) with different data types (compare e.g. listings C.6, P.5 and F.4) such as templates in C++ and the so-called duck typing in Python; • Fortran does not allow function calls to appear on the left hand side of assignment (see e.g. how the ptr pointers were used as a workaround in the cyclic_fill_halos method in listing F.8); • Fortran lacks support for arrays of arrays (cf. Sect. 2.2).”

In addition, Fortran users won’t be surprised to read the following, but would do well to make a note of it: “Fortran is a domain-specific language while Python and C++ are general-purpose languages with disproportionately larger users’ communities. The OOP features of Fortran have not gained wide popularity among users. Fortran is no longer routinely taught at the universities [28], in contrast to C++ and Python. An example of decreasing popularity of Fortran in academia is the discontinuation of Fortran printed editions of the ”Numerical Recipes” series of Press et al.”

The paper points out a few other shortcomings in working with Fortran: " The built-in standard libraries of Python and C++ are richer than those of Fortran and offer versatile data types, collections of algorithms and facilities for interaction with host operating system. In the authors’ experience, the small popularity of OOP techniques among Fortran users is reflected in the library designs (including the Fortran’s built-in library routines). What makes correct use of external libraries more difficult with Fortran is the lack of standard exception handling mechanism, a feature long and much requested by the numerical community"

But the least surprising finding for die-hard Fortran coders will be, “The performance evaluation revealed that: • the Fortran set-up offered shortest execution times,”

What are your take-aways from this study? I request you all to post your comments.

The attached project is a distillation of an error that I am having when calling a Fortran DLL from a VB.Net executable.

We are trying to use a callback from the Fortran to display output in a VB rich text box. The included project is from Visual Studio 2012 and Intel Visual Fortran Composer XE 2013 SP1 Update 1.

This is the routine causing the error:

      SUBROUTINE WRWIN(OUTSTR)
C*
      USE IFCOM               ! defines CONVERTTOBSTR and FREESYSSTRING routines
      USE VB_WRWIN_MOD        ! defines VB_WRITEWINDOW VB routine
      
      INTEGER           IRC           ! <i> - screen unit to write to
      CHARACTER*(*)     OUTSTR        ! <i> - string to print

      POINTER      ( P2, MY_STR_OUT )
      INTEGER*2      MY_STR_OUT(128)
      
      P2 = CONVERTSTRINGTOBSTR( TRIM(OUTSTR) )
      CALL VBWRITEWINDOW1( P2, IRC )
      
      RETURN
      END

After the call to VBWRITEWINDOW1, execution stops in Visual Studio with "Windows has triggered a breakpoint in HelloWorld_Basic.exe. This may be due to a corruption of the heap, which indicates a bug in HelloWorld_Basic.exe or any of the DLLs it has loaded.

Added complications:

If I choose the Target Framework for the VB project as ".NET Framework 2.0", the program compiles and runs fine. This error only occurs when I change the framework to .NET Framework 4.5.

SLN file is in the HelloWorld_Basic folder. Both VB and Fortran projects are included in the same solution.

Any help would be greatly appreciated.

dave

I guess its a different operating system entirely, but is there a way to generate executable code here

that I can migrate over to a tablet? Or does that require a separate compiler I would have to install on the

tablet?

I am not even sure I can compile any Fortran programs on a tablet.

Hi all,

i'm working on a main routine with many other subroutine in a contains block. In the main one, I defined some format labels but I can't use them in the contains block : they are no more defined. At the moment, I avoid this problem by redefined format labels in each subroutine in the contains block ; but this solution isn't really suitable. Is there a way to define these labels only once ?

Thanks,

Sebastien.

I am currently migrating a project from VS6/CVF6.6 into VS2012/IVF2013.  The way the FORTRAN libraries were set up in my project, I had a folder consisting of .f files and a folder of .for files generated from the .f files using a custom build tool.

Under VS6/CVF6.6, I was able to run the custom build tool for each .f file without compiling them. I have not found a way to accomplish excluding the .f files from the build while still running the custom build tool on them under the new VS2012/IVF2013. Am I correct in assuming that this is no longer supported by VS2012/IVF2013?

If the above will not work, I know that I could change the .f extensions to something else (.src or similar) and exclude those files from the build while still running the custom build tool on them. Is there a way, then, for me to use the FORTRAN editor for these .src files without adding them as FORTRAN files in the IVF options (because that would cause me to have the same issue I had when they were .f files)?

This is just a general question for peoples opinions on the VALUE attribute used in subroutines. I know it The VALUE attributie is sometimes necessary for interoperability with C, but my interest is what would be the benefit beyond that compared to INTENT(IN). I am assuming  that it makes no sense to have both at the same time.

Below is a simple example of what I am talking about

SUBROUTINE DOUBLER(X,Y) 
  REAL,      VALUE::X
  REAL,INTENT(OUT)::Y
  Y=2.*X
END SUBROUTINE

or

SUBROUTINE DOUBLER(X,Y) 
  REAL, INTENT(IN)::X
  REAL,INTENT(OUT)::Y
  Y=2.*X
END SUBROUTINE

Or another example would be:

FUNCTION DOUBLER(X) RESULT(Y) 
  REAL, VALUE::X
  REAL::Y
  Y=2.*X
END FUNCTION

or

FUNCTION DOUBLER(X)   RESULT(Y) 
  REAL::X                             !FUNCTION IMPLICITLY USES IN
  REAL::Y
  Y=2.*X
END FUNCTION

I have a working 32-bit software library written in Fortran with low-level stuff in C/C++ It has worked for years.

It is fine.

When I re-build the library in 64-bit mode, none of the C functions are linked in. I've checked the linker options, and they all seem to be right. The project appears to be referencing the 64-bit libraries.

Would someone mind just looking some sample  INTERFACE code and tell me whether there is anything at all that would cause a problem 

      SUBROUTINE PBZQS(MODE, IXORIG, IYORIG, NX, NY)

      INTEGER MODE

      INTEGER IXORIG, IYORIG

      INTEGER NX, NY

      INTERFACE

        SUBROUTINE JB_ZBSpecInquireImageSize(MODE, IXORIG, IYORIG, NX,

     1      NY)

          INTEGER MODE

          INTEGER IXORIG, IYORIG

          INTEGER NX, NY

          !DEC$ ATTRIBUTES C, ALIAS: '_JB_ZBSpecInquireImageSize' ::

     1      JB_ZBSpecInquireImageSize

          !DEC$ ATTRIBUTES VALUE :: MODE

          !DEC$ ATTRIBUTES REFERENCE ::  IXORIG, IYORIG, NX, NY

        END

      END INTERFACE

      CALL JB_ZBSpecInquireImageSize(MODE, IXORIG, IYORIG, NX, NY)

      END

The linker comes up with:unresolved external symbol'_JB_ZBSpecInquireImageSize

Reassurance from someone "that should work" is all I need.

I observe that the project includes the library comdlg32.lib. Is that going to be right for a 64-bit application?

Is there an easy way to look at the contents of the .lib file that is being linked in?