Hello, and good afternoon!
Concerning: Compiler mogration to your product / program worked well with other compiler (Lahey) for many years - here "insufficient virtual memory" at runtime -
To introduce ourselves: We are a team of 3 developers, in the process of testing Intel Fortran for migration of existing code to it (using evaluation version of compiler). As you probably hear often with Fortran, it has a lot of legacy code (F77) included.
We are planning for purchase of 2 or 3 licenses of the intel fortran compiler as soon as the main issues, which I'll outline below, are resolved, possibly with your help.
Platform: Windows, currently testing on both x32 and x64 -- and it ist NOT from within visual studio - but essentially commandline -- so far we work with Eclipse so commandline invoking from Eclipse appears as a quick way do it. Setting up with the prerequisites (free Microsoft studio and SDKs installed as needed for linking especially) and usage of scripts as provided (ifortvars.bat calling cascade of others) is in place --
as is evidenced in the fact that it compiles (small changes to the code itself were necessary such as how to process commandline arguments etc.
If there is any great way for setup in Eclipse, setting the environment there, we'd certainly appreciate that also.
The current plan is to see whether we will be able to manage the conversion -- as we have a run time error that looks like a menory leak of sorts (I dunno whether it actually is but it looks like it). That wasn't ever observed with an exe compiled with the old compiler.
This appears everytime the program runs *long enough* - and not right after start but after a few minutes of running (numerical calculations).
If you just start the gui (see below details what we use) and use it or let it sit there open, nothing bad happens with the memory (there are window redraw issues, but I save this for another time or get it worked out - unless you tell me this may give some clues for the crash problem at hand).
So, no program crash just from the gui. Also, if you start a "calculations" job (number crunching job) and if it is short enough to finish, there will also be no program crash.
I can observe that the "RAM" used by the process grows rapidly, up and until the breakdown. For comparison: A "Healthy" version of the application uses about 18MB RAM just when the gui is started; 170MB RAM wenn doing a "calculations" job, as per taskmgr. Used RAM with the intel compiled version is now gradually growing up to 1.4GB (on my machine) before the crash. GUI alone is just as small as it should be. This happens with both x32 and x64 versions. If a "calculations" job is short enough then the program does not crash. If you do not close the application (gui) and start another job it will add memory and then crash, i.e.; the same job as before (that went through) may now crash real soon.
Some code details that I want to mention: From the "old age" there are still quite a number of common blocks, which generate warnings at compile time. I may send it to you, see below. Also, I studied the forums and it is believed that ALLOCATE statements can, at times, cause problems. We do have them in the code but I believe they are not executed the way I test right now.
I have prepared additional information;
Please find below the error message. Also find the output of the "set" command in cmd window and one compiler log.
We use Intel Composer XE 2013; also Microsoft Visual Studio 10.0 and Windows SDK 7.1, as visible in the environment variables output if you need it.
The environment as for the information I am forwarding to you is x32. In the end, we plan to to a x64 application though.
We also use a toolkit called Winteracter for graphical user interface programming of our application. The linked libraries are recongnizable in the compile messages.
No other libraries are linked into the executable. Other than what the compiler asks us to. We had "unresolved externals" initially and I researched the libraries that need to be linked. I added them manually into the makefile and they are visilble in the compile protocol.
No DLLs are created or called at this stage (That is planned and was done before but we first want to get the basics right).
If you could get back to us and possibly direct us in the right direction, suggest tests we should perform, compiler flags and such, please let us know.
I did read through the forums but so far found no answer to my issues. If this is Steve who will answer I have read up on how you've helped others as well.
It seems to me that our setup here is slightly different from what many people use (Eclipse rather than Visual Studio).
Also, I would like to say thank you in advance for your help.
If we get our program converted successfully, we intend to become loyal customers; we were with Lahey for 17 years; they seem to have come to some sort of end with compiler development, especially on Windows.
By the way we also consider Linux. We are regular users of Linux (for other tasks at the moment) but it may also be an option for the development work in question. It seems to be far less compicated to set up the environment there (not using something as Visual Studio). I think I played with a trial version of the compiler once. We would consider switching if, for example, you told us that this avoids issues that can cause the present problem on Windows that I described.
Here is how the error is announced. 2 version of the message. I am curious why there are 2 ways by the system to report it. I have not yet nailed which of the 2 messages appears when. Are there even 2 general problems present?
forrtl: severe (41): insufficient virtual memory
Image PC Routine Line Source
adcos_0162.exe 004F4934 Unknown Unknown Unknown
adcos_0162.exe 004C2E06 Unknown Unknown Unknown
adcos_0162.exe 004AB1B2 Unknown Unknown Unknown
adcos_0162.exe 004772A8 Unknown Unknown Unknown
adcos_0162.exe 001786D1 Unknown Unknown Unknown
adcos_0162.exe 0017374F Unknown Unknown Unknown
adcos_0162.exe 00113715 Unknown Unknown Unknown
adcos_0162.exe 002E2C1C Unknown Unknown Unknown
adcos_0162.exe 0027CCBF Unknown Unknown Unknown
adcos_0162.exe 004A86F3 Unknown Unknown Unknown
adcos_0162.exe 0046A832 Unknown Unknown Unknown
kernel32.dll 752F33AA Unknown Unknown Unknown
ntdll.dll 77609EF2 Unknown Unknown Unknown
ntdll.dll 77609EC5 Unknown Unknown Unknown
forrtl: severe (41): insufficient virtual memory
Stack trace terminated abnormally.
UPDATE: I noticed that the makelog.txt file gives only standard output; warnings appear elsewhere (standard error?), therefore - here is a snippet of it. This repeats as the common blocks are called from several routines. This snipped may all be unimportant - but here it is, just in case.
ifort -Qvec-report0 -include:"c:\winteval\lib.if8" /heap-arrays /assume:byterecl /c fed_0264_1.f90
Intel(R) Visual Fortran Compiler XE for applications running on IA-32, Version 13.0.0.089 Build 20120731
Copyright (C) 1985-2012 Intel Corporation. All rights reserved.
fed.inc(16): remark #6375: Because of COMMON, the alignment of object is inconsistent with its type - potential performance impact [VOLALL]
real*8 volAll ! Volumen (Verdraengung) jedes Elementes (basierend nur auf Aussenquerschnitt)
fed.inc(93): remark #6375: Because of COMMON, the alignment of object is inconsistent with its type - potential performance impact [FXAERONABE]
fed.inc(93): remark #6375: Because of COMMON, the alignment of object is inconsistent with its type - potential performance impact [FYAERONABE]
fed.inc(94): remark #6375: Because of COMMON, the alignment of object is inconsistent with its type - potential performance impact [FXAERONABE_OLD]
fed.inc(94): remark #6375: Because of COMMON, the alignment of object is inconsistent with its type - potential performance impact [FYAERONABE_OLD]
fed.inc(91): remark #6375: Because of COMMON, the alignment of object is inconsistent with its type - potential performance impact [T_H_EIN]