I am a beginner of fortran, now I have a code which debugging with error 7976.
integer,pointer :: ele_concentrate( : ),ele_c( : )
double precision,pointer::vcl( : , : )
I am writing a subroutine intended for redistribution to other coders in a static library:
Subname (irow, icol, ra, rb, ...)
IF (irow == 0) irow = INT(ra)
IF (icol == 0) icol = (..something..)
The first two arguments, irow & icol (among others), are altered with the intent of returning updated values to the caller. The concern is that for some users, and in most cases, the routine case is
irow = 0
icol = 0
CALL Subname (irow, icol, ra, rb, ...)
I built a 32-bit DLL with Visual Fortran V11.1.067 within Visual Studio 2008 on my computer. The program is supposed to work like this:
EXCEL VBA (32-bit) calls “C:\Test\AA.dll” via the absolute path. Then “AA.dll” calls 3 others (libmmd.dll, msvcr90.dll, svml_dispmd.dll), which are all located in the same path “C:\Test\”. (The 3 dlls are actually Fortran’s inherent dlls, copied from the folder “…\lib\ia32”). It works fine on my computer. But on other computers, VBA always reports the “Run-time error 53: C:\Test\AA.dll not found”.
I am seeing very long compilation times, both debug and release, for routines where I am accessing recursive data structures in a certain way.
I have a Type like this:
Hello I'd like to report a possible bug in Intel Fortran compiler, I was using: Intel(R) Visual Fortran Compiler XE for applications running on IA-32, Version 22.214.171.124 Build 20140130 but the same problem exhibits on Win64 and Linux. It seems that when a file is opened in stream formatted mode and read using non-advancing read, it makes up character at position 8192 (and multiples). Example program is attached, the output is bellow.
Since I installed the last update for Intel Visual Fortran Composer XE(Visual Studio 2010), I can not create a dialog box as I used to create using Compaq Visual Fortran.
Please, can someone help me in this way?
Carlos A Santos.
Some time ago I converted a large numerical codebase over to the Intel Visual Fortran compiler. So far we have been unable to make the switch to IVF as we are seeing an unacceptably large discrepancy between the new simulation results and those produced by our old compiler. After some work I have managed to identify the source of problem - the deviation seems to be seeded by an error in the last digit of a floating point calculation in the IVF build:
x = 1.0000000/8.5404000
the correct answer is:
x = 0.11709053
the IVF answer is: