Hi,

I have a code which serves as a communication tool between Fortran and VB. It was originally converted from Lahey to Intel 32-bit and it doesn't run on 64-bit. Any help would be appreciated to convert it to 64-bit.

Thanks,

Serra

Based on past forum topics, I suppose unexpected internal compiler errors (ICE) has been a problem with any upgrade with past versions of Intel compilers, but this was a first for me. I recently upgraded to Fortran Compiler XE 2013 from XE 2011 and code that has worked without errors for nearly 15 years in Compaq Visual Fortran as well as Intel Fortran 9 and XE 2011 started giving an internal compiler error (ICE C00005). Based on previous Steve Lionel's responses to similar errors on many posts in this forum and the fact that this code has worked without errors in previous versions, I figured it is a compiler bug and attempted several code tweaks such as removing/inserting comment lines, creating code listings, etc. After many failed attempts at such code tweaks, I hit upon a USE statement that did not have a ONLY keyword; I modified the statement to have the ONLY keyword to only access the needed entities from the module and voila, the ICE disappeared! That is,

USE MyModName

to

USE MyModName, ONLY : PublicVar1, PublicVar2

Owing to the proprietary aspect, I can't post the exact code here. But I'll try to isolate and simplify the code and submit to Intel Premier Support and they can hopefully fix the issue in one of the future updates to Compiler XE 2013.

For those of you who can't turn the "ship around" and can't wait through the Intel update cycle for bug fixes, the above information is just to let you know minor code changes - note they could be anything, not necessarily USE statements - might help you get around this issue. In my case, my preference is always to include the ONLY keyword on all USE statements and there was a silver lining after all. I understand it may not be the case always.

Separately though, it is distressing to come across such compiler bugs. I can understand if they were to happen with the newer Fortran 2003/2008 features, but not with fairly standard Fortran 90/95 that has been handled since the days of Digital Fortran circa late 90s. Can any of the Intel staff shed some detail on what's commonly the root cause of such regressions in their compiler versions?

I have an executable that goes into an infinite loop before it executes the first line of code. I put a number of write statements at the start to see if they were hit. But It doesn't generate any output.  The code has /Qopenmp and will have several threads eventually if that matters, and has calls to several DLLs eventually too.  The same code built on another machine works fine.  Any idea what it could be executing?

Based on past forum topics, I suppose unexpected internal compiler errors (ICE) has been a problem with any upgrade with past versions of Intel compilers, but this was a first for me. I recently upgraded to Fortran Compiler XE 2013 from XE 2011 and code that has worked without errors for nearly 15 years in Compaq Visual Fortran as well as Intel Fortran 9 and XE 2011 started giving an internal compiler error (ICE C00005). Based on previous Steve Lionel's responses to similar errors on many posts in this forum and the fact that this code has worked without errors in previous versions, I figured it is a compiler bug and attempted several code tweaks such as removing/inserting comment lines, creating code listings, etc. After many failed attempts at such code tweaks, I hit upon a USE statement that did not have a ONLY keyword; I modified the statement to have the ONLY keyword to only access the needed entities from the module and voila, the ICE disappeared! That is,

USE MyModName

to

USE MyModName, ONLY : PublicVar1, PublicVar2

Owing to the proprietary aspect, I can't post the exact code here. But I'll try to isolate and simplify the code and submit to Intel Premier Support and they can hopefully fix the issue in one of the future updates to Compiler XE 2013.

For those of you who can't turn the "ship around" and can't wait through the Intel update cycle to bug fixes, the above information is just to let you know minor code changes - note they could be anything, not necessarily USE statements - might help you get around this issue. In my case, my preference is always to include the ONLY keyword on all USE statements and there was a silver lining after all. I understand it may not be the case always.

Separately though, it is distressing to come across such compiler bugs. I can understand if they were to happen with the newer Fortran 2003/2008 features, but not with fairly standard Fortran 90/95 that has been handled since the days of Digital Fortran circa late 90s. Can any of the Intel staff shed some detail on what's commonly the root cause of such regressions in their compiler versions?

When I start a new project I cannot select the "Intel Visual Fortran". Hence I cannot build Fortran code. I installed the Visual Fortran Composer XE with the "w_fcompxe_2013.1.119.exe" file. What did I do wrong?

Andreas

When passing a contained function the variables in the parents scope are not thread safe in 12.1 and earlier. Was this fixed in 13 ?

Hello, all

I've faced a problem about :forrtl: severe (174): SIGSEGV, segmentation fault occurred when I try to run FVCOM code on Linux (colorado) system.

orrtl: severe (174): SIGSEGV, segmentation fault occurred

Image              PC                Routine            Line        Source

fvcom              0000000000521FAE  Unknown               Unknown  Unknown

fvcom              000000000055B222  Unknown               Unknown  Unknown

fvcom              0000000000766292  Unknown               Unknown  Unknown

fvcom              000000000069FDB8  Unknown               Unknown  Unknown

fvcom              000000000073C0AA  Unknown               Unknown  Unknown

fvcom              0000000000444E1C  Unknown               Unknown  Unknown

libc.so.6          00002AAF4D792994  Unknown               Unknown  Unknown

fvcom              0000000000444D29  Unknown               Unknown  Unknown

I want to use -heap-arrays as recommended, however, I'm not sure if I used the right format of it.

-bash-3.2$ ifort -heap-arrays 10 fvcom

fvcom:(.rodata+0x0): multiple definition of `_IO_stdin_used'

/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o:(.rodata.cst4+0x0): first defined here

fvcom: In function `main':

(.text+0xe0): multiple definition of `main'

/curc/tools/nonfree/redhat_5_x86_64/ics_2011.0.013/composerxe-2011.0.084/compiler/lib/intel64/for_main.o:/export/users/nbtester/efi2linux_nightly/branch-12_0/20101007_000000/libdev/frtl/src/libfor/for_main.c:(.text+0x0): first defined here

fvcom: In function `_fini':

(.fini+0x0): multiple definition of `_fini'

/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crti.o:(.fini+0x0): first defined here

fvcom: In function `_start':

(.text+0x0): multiple definition of `_start'

/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o:(.text+0x0): first defined here

fvcom: In function `_init':

(.init+0x0): multiple definition of `_init'

/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crti.o:(.init+0x0): first defined here

fvcom: In function `__data_start':

(.data+0x0): multiple definition of `__data_start'

/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o:(.data+0x0): first defined here

Any suggestion to solve this problem?
Thanks.

Qianru

I have a problem with a Quickwin application. It is an application I have worked on and regularly updated for many years that has suddenly become unstable. I have mouse events registered against a couple of child windows. When I make a mouse click on the window the programs crashes with a stack dump.

Under debug the program generates an exceptions like below:

First-chance exception at 0x7769fb81 in fil70.exe: 0xC0000008: An invalid handle was specified.

The stack at this point is as below.

ntdll.dll!7769fb81()        

[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]

ntdll.dll!7769fb81()        

KernelBase.dll!74dd0fa2()

fil70.exe!_for__release_lun()  + 0x1bc bytes 

fil70.exe!_GETUNITQQ()  + 0x4e bytes         

fil70.exe!_DeReferenceGetUnitPointer()  + 0x13 bytes          

fil70.exe!__QWGChangeMouseStatus()  + 0x12c bytes         

fil70.exe!__QWGraphWndProc@16()  + 0x338 bytes

 If I ignore the exception (I will get three or four more that are the same) execution control drops into the correct call back function that was  registered against the mouse event and also return correct parameters for the event (unit, button event ,keystate,  position).

I am currently using Intel(R) Visual Fortran Composer XE 2011 Update 9 with Integration for Microsoft Visual Studio* 2010, 12.1.3526.2010. I was planning to buy the update to the  latest level but I don’t expect that to fix anything.

I am running on W7 Professional x64 SP1  by the way.

Any ideas what I can do to resolve this? I

Hi 

Actually, this is the first time for me to try to pass arrays from VB.net to Dll created by FORTRAN, but I had too much difficulty to do that. Usually I'm having this error “An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)”, and I don't know why and what does it mean? .following is a very simple example I'm trying to do using VB.net:

Imports System.Runtime.InteropServices

Module Module1    

Declare Sub FortranDLL Lib "C:\Users\Shabana\Desktop\DLL Project\Dll2\VBPROG\Dll2.dll" Alias "FORTRANDLL" (<[In](), Out()> ByVal Array1() As Int32, ByRef Foo As Int32)

End Module

Public Class Form1    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click        

Dim I As Int32        

Dim Test As Int32() = {1, 2, 3, 4, 5, 6}        

FortranDLL(Test, Test.Length)        

For I = 0 To 5            

TextBox1.Text = Str$(Test(I))        

Next I    

End Sub

End Class

Also this is the Fortran code to create the Dll file

Subroutine FortranDLL( Array1, upbound )

!DEC$ ATTRIBUTES DLLEXPORT, ALIAS: 'FORTRANDLL' :: FortranDLL

!DEC$ ATTRIBUTES REFERENCE :: Array1

!DEC$ ATTRIBUTES REFERENCE :: upbound    

Implicit None

! ...argument declarations    

Integer(4) :: upbound           

Integer(4) :: Array1(1:upbound)         

  Array1 = Array1 + 10

End Subroutine FortranDLL

I hope that I could able to make it clear , and I will be do appreciated if you could help me solving this problem.

Consider the code below

program Console2
    implicit none
    integer :: a(10000,10000)   # line1
    
    a=1
    print *, 'Hello World'
end program Console2

My compile enviroment is VS2010+intel Parallel Studio XE 2011+Win7.

the code line1 defined a variable “a" with size 4*10000*10000=400MB, and the program pass the compile and run. I remember i got an error "stack oveflow" when i define a big array before. Why it didn't pop the error this time?

I noticed that it says it had "visual studio 2010 shell" contained in the download file.

Why aren't we getting the latest VS dated 2012, with the bugs corrected?

Is that a separate purchase?

Is the latest VS compatible with the latest Fortran?

For the longest time, I and others have been confounded by the lack of specificity in compilation and runtime error messages.  A good example of these is the floating * error messages one gets at runtime.  Back in July (http://software.intel.com/en-us/forums/topic/277207#191012), I got a "M6201 error DOMAIN" message.  After adding a critical switch ( /fp:0 ), I got this error:

forrtl: error(73): floating divide by zero

which helped me trace the problem (a "constant" wasn't very constant after all).  I fixed the problem.

Now, for a different reason and at a different spot,  I'm getting:

forrtl: error(65): floating invalid

The actual problem at the choke point isn't obvious and is being investigated.  But meanwhile, I really wonder if anyone can please enlighten me as to what the difference is between error(73) and error(65).

Hi,

Can anyone help me out on how to include the resource file generated by resedit into intel visual fortran?

I couldn't seem to make it work..

I tried making a dialog in resedit and then added the .rc and .h file in my solution in visual studio. 

I then added a custom build setup for resource.h using steve's guide below:

Quote:

Steve Lionel (Intel) wrote:

ResEdit should generate both a .rc and a .h. You will need to add both of those to your Fortran project and add a custom build step for the .rc:

1. Add Resource.h to your project using File>Add Existing Item....

2. Select the Resource.h file in the Solution View and the select View>Property Pages from the main menu bar.

3. Set the Command Line option to use the deftofd tool by entering:

   deftofd resource.h resource.fd

4. Set the Description option to Generating Fortran include file...

5. Set the Outputs option to resource.fd.

6. Click OK.

Problem is i couldn't compile my program successfuly. I always get the following error:

Error 1 fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt LINK

It would be nice if someone could post a complete guide for beginners in using resedit in intel visual fortran..

Thanks in advance. ^^ 

My understanding is that I can leave out explicit enumerstion of imbedded matrices

in the argument list. How does the called routine know the dimensions of the matrix?

Of course with Fortran 77, that feature was not available, but is with Fortran '95

Example with a 3x3 imbedded matrix:

REAL*8 A(20,20),SUM

CALL SUM_IT( A(3:5,5:7) , SUM)

END

SUBROUTINE SUM_IT(A,SUM)

REAL*8 A(:,:),SUM

SUM=0.0

DO IRA=1,NRA

DO ICA=1,NCA

SUM=SUM+A(IRA,ICA)

END

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

Now, how would the subroutine be able to get the quantities NRA and NCA?

I think there is a function I can call.

Is that the usual way to get those quantities?

I realize there is a SUM function, but this is just a simple example.

I have used Digital, Compaq and now Intel Fortran for some time. I took the offer to
upgrade from Fortran to a package with Fortran and Parallel support that included C
all for an attractive price. Later Intel offered a product which was only Fortran
and Parallel support with no C.

Is it possible to renew to a product which has only the Fortran and Parallel support
without the C. This would be a "downgrade" from the triple bundle to a double bundle.

So far my reseller either does not understand the question or is unwilling to
put any effort into finding out if such a restricted renewal is possible.

Thanks

I have a problem creating static libraries in IVF XE 13.1.0.149 with VS 2008. The "Lib" executable could not be found when creating the library. Also, after upgrading to the latest IVF version, a warning message saying that "mspdb80.dll" or "mspdb100.dll" could not be found occurs when compiling the 64-bit version. The error messages are the following:

++++++++++++++++++++++++++++++++++++++++++

32-bit build:

Compiling with Intel(R) Visual Fortran Compiler XE 13.1.0.149 [IA-32]...
ifort /nologo /debug:full /Od /warn:interfaces /module:&quotDebug\\&quot /object:&quotDebug\\&quot /Fd&quotDebug\vc90.pdb&quot /traceback /check:bounds /check:stack /libs:static /threads /dbglibs /c /extfor:f /Qvc9 /Qlocation,link,&quotC:\Program Files (x86)\Microsoft Visual Studio 9.0\Intel Fortran\Microsoft Files\VC\\bin&quot &quotY:\Documents\Matrix\ISIS2_euclid\mv\BlasDotWrap.f&quot
Creating library...
Lib /OUT:&quotDebug/Forlib.lib&quot /NOLOGO &quotDebug\BlasDotWrap.obj&quot
xilib: executing 'lib'
xilib: error #10037: could not find 'lib'
Lib: error spawn_errno_default: spawn('C:\PROGRA~2\Intel\COMPOS~1\bin\ia32\xilink.exe') failed, errno=0

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

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

64-bit build:

Compiling with Intel(R) Visual Fortran Compiler XE 13.1.0.149 [Intel(R) 64]...
ifort /nologo /debug:full /Od /warn:interfaces /module:&quotx64\Debug\\&quot /object:&quotx64\Debug\\&quot /Fd&quotx64\Debug\vc90.pdb&quot /traceback /check:bounds /check:stack /libs:static /threads /dbglibs /c /extfor:f /Qvc9 /Qlocation,link,&quotC:\Program Files (x86)\Microsoft Visual Studio 9.0\Intel Fortran\Microsoft Files\VC\\bin\amd64&quot &quotY:\Documents\Matrix\ISIS2_euclid\mv\BlasDotWrap.f&quot
warning #31001: The dll (mspdb80.dll or mspdb100.dll) for reading and writing the pdb could not be found on your path. This is usually a configuration error.Compilation will continue using /Z7 instead of /Zi, but expect asimilar error when you link your program.

Creating library...
Lib /OUT:&quotx64\Debug/Forlib.lib&quot /NOLOGO &quotx64\Debug\BlasDotWrap.obj&quot
xilib: executing 'lib'
xilib: error #10037: could not find 'lib'
Lib: error spawn_errno_default: spawn('C:\PROGRA~2\Intel\COMPOS~1\bin\Intel64\xilink.exe') failed, errno=0

Forlib - 2 error(s), 1 warning(s)

++++++++++++++++++++++++++++++++++++++++++

The workaround/solution for these problems is to modify the "Executables:" path in VS 2008 as follows:

1.) Select "Tools->Options"

2.) Expand "Intel Composer XE"

3.) Expand "Visual Fortran"

4.) Select "Compilers"

5.) For 32-bit:
     a.) Under "Platform:", select "Win32"
     b.) Select "..." for "Executables:"
     c.) Add the following:
         "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin"
         under
         "$(VCInstallDir)BIN"
     d.) Select "OK"

6.) For 64-bit:
     a.) Under "Platform:", select "x64"
     b.) Select "..." for "Executables:"
     c.) Add the following:
         "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64"
         under
         "$(VCInstallDir)bin\amd64"
     d.) Select "OK"

The icons in the leftmost column do not appear anymore but are replaced by text (New post, Hot topic). The explanations for the icons are still visible at the bottom, without the icons. Bug or feature? I use Firefox.

I want to write a object of a derived type and i looked up the fortran2003 handbook,  I think the "Defined Input/Output" can handle it. But i cannot compile the example in the "Defined Input/Output" sector. do the intel fortran support defined input/output?

Hi,

I have a short question when I use x64 as my active solution platform for my codes, I encountered with following two errors:

"An ALLOCATE shape must not be given for a scalar object."

"This symbolic name is not an intrinsic function name or an intrinsic subroutine name.  "

But when I use Win32 platform, I have no warning or these errors.

What is the problem ? Should I use Win32 instead of x64 ? But if I use Win32 platform then I can have problems with the arrays ? Do you have any recommedations ? Thanks.

In the past month, Visual Studio has been randomly hanging (it freezes for ~10 seconds and then resumes) while I edit code.  Last night, I discovered that the open parenthesis [i.e. "("] character is the problem.  For instance, if I am starting to type a conditional, a type, case, or array index, or even just a single open parenthesis, e.g.

if (

type(

case(

real_array(

(

I still have this issue with 13 (update2).  I believe that it is related to on the fly parsing of file as the duration is much longer for large files.

Has anyone else experienced this delay?  If so, how did you resolve it.  

Thanks.