Hello everyone,

I have this problem, hope that you can help me out:

There is a subroutine in Fortran code that has been given to me. This Fortran code is acually a simulation model of a physical process, so there is a criteria of simulation speed. I compiled the Fortran code into a DLL file.

Then the DLL subroutine is called from a Fortran program by using Windows API functions LoadLibrary and GetprocessAdress, it gives a the speed ratio of 770 which means that it takes 1 second to simulate the physical process in 770 seconds real time

Next, i do the same thing but this time in C++, and this gives me a speed ratio of 380 which is 2 times slower than the calling from Fortran program

i have tried to get through the problem by setting the Runtime library option when compiling C++ program to  "Multithreaded DLL" which was set to the DLL but it did not resolve the problem

Anyone has any idea of what has happened with the call from C++?

Thanks for your help,

The following piece of code thorws a run-time error in my code and I do not understand why, since what I do seems to be standard to me and is done at many other positions in my code wihtout problem. Moreover the code is been used for 5 years now with an older compiler version without any problems.

The error appears only in the release version with maximal speed optimization.

! variables: Reference is a own structure holding a logical member "Master"
Type(Reference), pointer :: pReference
! execute that throws a run-time exception only in release version if maximize speed optimization is enabled:
! namely: "Attempt to use pointer pReference when it is nit associated with a target"
pReference => Null()
 allocate(pReference, stat = ierr(1))
 if (ierr(1) .NE. 0) then
 my_status = 3
 if(present(STATUS)) STATUS = my_status
 return
 end if
 if(associated( pReference)) then 
 ! set flag 
 pReference%Master = .FALSE. 
 end if

 As I said the error appears only in the release version so it is hard to judge what actually happens. But even inside the if clause where I checked if the pointer is associated another if clause checking the same statement will tell me that this is not the case... which obvioulsy cannot be true otherwise the code would no enter the clause.

Thanks everybody for your help!

Regards,

Felix

Thanks for the "start new topic" link, Steve.  I was trying to figure it out.

I tried to generate a listing file over the weekend -- it (VS 2008, Intel 13) will generate a source with asm listing but if I ask for just a listing -- it doesn't.  What gives?

ASM listing is quite challenging to try to read -- because I was just trying to see if the #defines that I had done were generating the correct code.

Hello everybody

I have a problem. made a code for solving a BVP equation with the SHOOTING method. I debug the program with no errors in my "PGI Visual Fortran 2010 with Visual Studio 2010 Shell" without any problems.
But when i try to debug it on  "Fortran PowerStation4" i get this error :

First-chance exception in 1.exe: 0xC0000090: Float Invalid Operation.
The program 'C:\MSDEV\Projects\1\1___Win3\1.exe' has exited with code 1 (0x1).

can anybody help me what's wrong?

thx :) 

Hi,

I'm getting an Internal Compiler Error from the move_alloc call in this code:

module test
  implicit none
  type :: derived
  end type derived
  type(derived), allocatable :: all_derived(:)
contains
  subroutine test_sub
    class(derived), allocatable :: temp(:)
    integer :: current_size, new_size
    current_size = size(all_derived)
    new_size = current_size + 1
    allocate(temp(new_size))
    call move_alloc(from=temp, to=all_derived)
  end subroutine test_sub
end module test

Commenting out the move_alloc gets rid of the ICE. I'm pretty sure its because I'm moving the allocation from a polymorphic (class) to a normal (type) allocation, and indeed making temp non-polymorphic also gets rid of the ICE. I'm pretty sure I shouldn't be doing that sort of move (it was a typo, temp wasn't meant to be polymorphic, anyway), but the compiler should probably give a better error message than just an ICE.

I'm using version 13.0.0.089 on Windows 7 x64:

Compiling with Intel(R) Visual Fortran Compiler XE 13.0.0.089 [Intel(R) 64]...
test.f90
C:UsersbmenadueGoogle DriveCodetesttest.f90(21): 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.
1>compilation aborted for C:UsersbmenadueGoogle DriveCodetesttest.f90 (code 1)

Cheers,
Ben.

Hello,

I am using Intel Fortran 11.1 trial version for last 2-3 weeks, I am getting so many debugging errors(which has been

suspected that version compactibility errors) so I am planning to install the latest trial version of Intel Fortran. May I know will it work for another one month if I install it in the same machine.

Can somebody kindly help me quickly?

Hi everyone;

I had a problem with paralellizing of fortran program here to share. My program had a three nested big do loops which were taking too much time to run. So, I decided to paralellize outside do loop (n=1,nszf) and then use it in some supercomuters in my university. My current Dell xps 8500 Windows 7 ultimate PC has 8 threads. here is that part of my program:

         !$omp parallel private(i,j,k,n,l,c) shared (nszf, nband) reduction (- : sk, r1)
         !$omp do
         do300 n=1,nszf            ! nszf=139020
         i=n
         do290 l=2,nband          ! nband=7000
         i=i+1
         if (sk(n,l)) 240,290,240
 240   c = sk(n,l)/sk(n,1)
         J=0
         do270 k=l,nband
         j=j+1
         if(sk(n,k)) 260,270,260
  260  sk(i,j)=sk(i,j)-c*sk(n,k)
  270 continue
  280  sk(n,l)=c
          r1(i)=r1(i)-c*r1(n)
  290 continue
  300 r1(n)=r1(n)/sk(n,1)
         !$omp end do
         !$omp end parallel

Without omp clauses program runs well, but using paralell gives some errors. I think program have problem in private, shared, and reduction clauses parts. sk is a stiffness matrix and r1 is force array. It should be noted that this program is the same famous Gaussian elimination method to solve a unknown in a matrix. Is it true to use reduction for matrix and arrays this way here?  please let me know where the problem is?

Thanks  

I wrote a FORTRAN program using the date_and_time function. The source follows below. The date_and_time function returns the wrong time in the cygwin environment: I am not in UTC, so czone should be +0100. However, in the windows cmd environment, the results are correct. The question is now: Why does the date_and_time function not work properly in the cygwin environment, when compiled with the ifort compiler, whereas date() and time() do? Do I miss setting some environment variables? Should I use some compiler options? I have posted this question also in the Cygwin mailing list, but so far, I still have no clue about what may be wrong.

In the following output, the lines "ctime:..." to "milliseconds..." are based on time_and_date. The line 15:54:49 is the correct time obtained by the time function, and the line 23-JAN-13 is the correct date obtained by the date function.

ctime: 20130123 
cdate: 145449.947 
czone: -0000 
@ 2013-01-23 14:54:49.947 
  year                 2013 
  month                   1 
  day                    23 
  diff wrt UTC            0  minutes 
  hours                  14 
  minutes                54 
  seconds                49 
  milliseconds          947 
  15:54:49 
  23-JAN-13 
 

I have done some experiments to narrow down the problem:
* compiling with gfortran: time_gfortran.exe gives correct result in Cygwin
* compiling with g95: time_g95.exe gives the correct result in Cygwin
* compiling with ifort: time_ifort.exe gives the wrong time in Cygwin

After copying cygwin1.dll, cyggfortran-3.dll and cyggcc_s-1.dll to the working directory, I get correct results
using the three executables in c:\windows\system32\cmd.exe.

I suspect that the intel compiler does a different system call for time_and_date than for date and time. I am still baffled why the same source runs fine for gfortran and g95. Notice however that for these compilers, the _date_ and _time_ functions are not defined. Hence the preprocessor exclusion in the source.

Regards,

Marten Jan

The following example comes from the documentation:

Consider the following 
example executed on 2000 March 28 at 11:04:14.5:
INTEGER DATE_TIME (8)
CHARACTER (LEN = 12)
REAL_CLOCK (3)
CALL DATE_AND_TIME (REAL_CLOCK (1), REAL_CLOCK (2), &
                      REAL_CLOCK (3), DATE_TIME)

This assigns the value  "20000328" to REAL_CLOCK (1), the value "110414.500" to REAL_CLOCK (2), and the value "-0500" to REAL_CLOCK (3). The following values are assigned to DATE_TIME: 
2000, 3, 28, -300, 11, 4, 14, and 500. 
 

The following is the source of my program:

program time_and_date 
implicit none 
character (len=8)  cdate 
character (len=10) ctime 
character (len=5) czone 
integer(4) ival(8) 
integer(4) yr,mon,day,hr,min,sec,ms 
call date_and_time(cdate,ctime,czone,ival) 
read (cdate(1:4),*) yr 
read (cdate(5:6),*) mon 
read (cdate(7:8),*) day 
read (ctime(1:2),*) hr 
read (ctime(3:4),*) min 
read (ctime(5:6),*) sec 
read (ctime(8:10),*) ms 
print *,'cdate        ',cdate 
print *,'ctime        ',ctime 
print *,'czone        ',czone 
print "('@ ',i4,'-',i2.2,'-',i2.2,'',i2.2,':',i2.2,':',i2.2,'.',i3.3)", yr,mon,day,hr,min,sec,ms 
print *,'year         ',ival(1) 
print *,'month        ',ival(2) 
print *,'day          ',ival(3) 
print *,'diff wrt UTC ',ival(4),' minutes' 
print *,'hours        ',ival(5) 
print *,'minutes      ',ival(6) 
print *,'seconds      ',ival(7) 
print *,'milliseconds ',ival(8) 
print * 
#ifdef IFORT 
   call time(ctime) 
   print *,ctime 
   call date(ctime) 
   print *,ctime 
#endif 
print *,'done' 
end program 
 

I renewed my Visual fortran license, but when I downloaded IVF 2013 build 1, I got

VS 2010. I want to see if the VS problems got corrected.

How do I get the latest VS 2012 build?

Thanks !

Is it possible for the compiler to indicate which modules are causing the problem when it fails with the error "The same named entity from different modules and/or program units cannot be referenced". I have a source file of some 8,000 lines which the complier is taking nearly 15 minutes to process giving this error and pointing to the first line in the file which is a commented out compiler directive - which isn't very helpful.

Is there any way of getting some indication from the compiler as to what it is doing? The source file is one of a number of files that are similar in that they are linked with the same libraries and are used to build similar GUIs. Currently they are all built in debug mode and nine out of ten projects build in seconds while this one source file takes an age to compile. (Or, at the moment, fail to compile.)

It's been quite a while since I posted.  I am still working to upgrade legacy (F77) code to F90.  Recently, I have stumbled onto situations in which procedures are being passed as arguments in the call.  I'm not sure how common this is; I had never seen it and discovered it quite accidentally.  This (I discovered) exlained the EXTERNAL statements in the specificaon part of certain routines.  Upon researching this, I believe I discovered a way to "convert" this structure to F90; it involves the use of the INTERFACE block.  I prepared a skeleton for illustration:

1) Can anyone please confirm that this template is appropriate?  (I realize I've omitted much detail; I'm trying to get the concept for now, with an eye toward parallelism.)

2) In the call to s.D, procedures B & C - which have their own arguments - are (of course) referenced as arguments.  How can procedures B & C be executed without arguments?

3) If the F90 structure is appropriate, will it work as well if all the procedures (s.A, s.B, S.D & f.C) are in the CONTAINS part of a Module?

I hope I have presented this clearly and appreciate any helpful feedback.  ( I also hope my pasted table appears as well as it does in the edit window; I've never tried this before.)

Allocatable components are not being finalized when their parent object is deallocated?

MODULE m
  IMPLICIT NONE
  
  TYPE :: Thing
  CONTAINS
    FINAL :: thing_Final
  END TYPE Thing
  
  TYPE, PUBLIC :: Parent
    TYPE(Thing), ALLOCATABLE :: a_thing
  CONTAINS
    FINAL :: parent_Final
  END TYPE Parent
CONTAINS
  SUBROUTINE thing_Final(obj)
    TYPE(Thing), INTENT(INOUT) :: obj
    PRINT *, 'Component final'  END SUBROUTINE thing_Final
  
  SUBROUTINE parent_Final(obj)
    TYPE(Parent), INTENT(INOUT) :: obj
    PRINT *, 'Parent final'  END SUBROUTINE parent_Final
END MODULE m
PROGRAM final_test
  USE m
  IMPLICIT NONE
  TYPE(Parent), ALLOCATABLE :: a
  ALLOCATE(a)
  ALLOCATE(a%a_thing)
  DEALLOCATE(a)
END PROGRAM final_test

[U:projectsFortranMiscFortranMisc]
>ifort /check:all /warn:all /standard-semantics "2013-01-29 final.f90"&& "2013-01-29 final.exe"
Intel(R) Visual Fortran Compiler XE for applications running on IA-32, Version 13.0.1.119 Build 20121008
Copyright (C) 1985-2012 Intel Corporation.  All rights reserved.
2013-01-29 final.f90(20): remark #7712: This variable has not been used.   [OBJ]
  SUBROUTINE parent_Final(obj)
--------------------------^
2013-01-29 final.f90(15): remark #7712: This variable has not been used.   [OBJ]
  SUBROUTINE thing_Final(obj)
-------------------------^
Microsoft (R) Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.
"-out:2013-01-29 final.exe"
-subsystem:console
"2013-01-29 final.obj" Parent final

In the above the parent object is finalizable, but I think even if it wasn't (no final:: parent_Final statement) the finalizer for a%a_thing should still be called.  Mentioned previously in http://software.intel.com/en-us/forums/topic/278463 and http://software.intel.com/en-us/forums/topic/284434 and possibly in other threads, so perhaps this is all well known, but I couldn't find a definitive issue id.

I have a large object oriented groundwater modeling code (e.g. 70K lines in ~100 files) written in Fortran 2003 (I use pointers, linked lists, pointers to procedures, classes extensively as every process model or dataset is an object).  When debugging and updating lower level classes/modules, I have to recompile nearly all the code over and over when testing, even though my changes do not affect other portions of the code.  Yes, this is the desired behavior of a compiler since code mods may affect other portions of the code, thus the need for dependency checks.  However, I am confident that my changes are simple and do not affect other portions of the code under these circumstances.  

Short of decomposing my code into separate libraries, is there a way to temporarily shut down dependency checks within Intel Visual Fortran (2013)?  

I accomplish this on my Linux box by removing my dependency list from the makefile, but I find that Linux debuggers (e.g. TotalView) are not nearly as convenient as Visual Studio.

Thank you.

NEVER MIND - I SEE the ERROR.......................

But it does not explain how to access the :LAPACK routines.

That include file doesn't work.

subroutine solve(a,x,b)

parameter nrhs=1;m=4;n=10

real*8 a(m,n),x(m,nrhs),b(m,nrhs)

!!!!!!!!!!!!!!!!!!!!!!!!!!!!

lda=m;ldb=m

call gelss(m,n,nrhs,a,lda,b,ldb)

end

Joining other complaints I see from time to time on this forum, I have to strongly object to the current state of the documentation. It is simply very difficult to use. As an example, consider the search for help on the subject of Quickwin. In the old CVF days, or IVF prior to the time (v.9 or 10?) that documentation was absorved into VS, I could call up help and navigate using a tree explorer as follows:

Visual Fortran >
     Compaq Visual Fortran >
          Programmers Guide >
               Using Quickwin
     ...which takes me to 8 Quickwin topics and many subtopics with extensive description of all aspects of Quickwin. The navigation was easy because the tree view explorer shows all levels with collapsable indexing. The Table of Contents shown by the explorer was complete and logical.

Now, I have to do

Library Home >
     Intel Fortran Compiler XE 12.1 User and Reference Guides >
          Getting Started >
               Using Microsoft Visual Studio > (MISPLACED!)
                    Working with Microsoft Visual Studio >
                         About Fortran Project Types >
                              Using Fortran Quickwin Application Projects
     ....which has one page only, containing the bare basics of how to run it, with a link to software.intel.com, which is a rabbit hole, to get another manual for addl info.

Besides being deeply nested, the "explorer" is very difficult to traverse because it does not show more than one level ahead or behind, and the organization is sometimes not intuitive. (Why is the general info on Quickwin projects stuck under Visual Studio? It has nothing to do with whether you're using the studio or the command line to launch the programs; then when you finally get there you find out that the real information does not even exist except at another location in cyberspace).

Please, please bring back the older type documentation that consisted of a single pdf document, with full and reasonable table of contents, and in which I can markup pages or even print out sections. I have even left CVF installed on my computer, just so I can use the documentation!

I am an experienced Fortran developer for 20+ years developing chemical engineering software for the energy industry. I have been using Intel Fotran (v 10.1.024) since 2008 as it was adopted by the AspenTech chemical engineering software as part of its simulator. However, my legacy programs that had been compiled successfully with several compilers including CVF (6.6C), experience many unexplained errors in Intel Fortran. My questions to the forum are:

1. Is there a list of settings available where Intel Fortran is completely compatible with legacy CVF code? One such setting is the option /iface:cvf and that eliminates many of the error messages but not all.

2. There are a number of cases where there are run-time errors that should not occur. For example, I have the following piece of code (written in simplified format to illustrate the point):

integer(4) :: i, m, n
real(8) :: t, x(3)
m = 3
n = 3
t = 0.0
do i = m+1,n
if (x(i) > 0.0) then
t = t + 1.0
end if
end do

In the above code, the do loop should not execute since m+1 is greater than n (4>3). However, Intel fortran executes the body of the loop resulting in an error since an attempt is made to access the fourth element of x. The locals window confirms that i=4 when the break point was encountered within the loop while executing the if statement. Again, other do-loops with a similar structure work fine.

3. Will it help to have a newer version of the compiler?

This is baffling and frustrating. Please help. I have avoided these problems by sticking to my legacy version of Compaq Fortran for several years but the new Windows 7 computer and AspenPlus are no longer compatible with CVF.

Best,

Avinash

Dr. Avinash R. Sirdeshpande

Director, Process Design and Modeling,
GreatPoint Energy
Chicago

This is an extract of the code:

 pure subroutine calculateAdvancedContactStressContact(aContactPair)
   type(ContactPairType), intent(inout) :: aContactPair
   integer j
   real(8) deltaVec(3)
   deltaVec(1) = 1.0D0
   deltaVec(2:3) = 0.0D0
   associate(aRegion => aContactPair%sides(1)%region)
      do j = 1, size(aRegion%contactRegions)
         associate(def => aRegion%contactRegions(j)%deflection)
            def%vector(1:3)%v = def%vector(1:3)%v - deltaVec
         end associate
      end do
   end associate
end subroutine 

<!--break-->

The error message is:

1>Compiling with Intel(R) Visual Fortran Compiler XE 13.0.1.119 [Intel(R) 64]...

1>ContactPair.f90

1>D:\dev\r14.5.1\Components\Source\Romax\StaticAnalysisServer\ContactPair.f90(103): error #7617: This host associated object appears in a 'defining' context in a PURE procedure or in an internal procedure contained in a PURE procedure.   [DEF]

I have an application that loads a bitmap in a window that works on WinXP, WinVista and Win7 X86 and WinXP X64 machines but not a Win7 X64 machine. It returns -1 and I need help to find the reason. I did a forum and documentation search with no helpful results.

Neels

I've migrated to a new computer (64 bit).  I'm trying to build my projects using IVF11.1.072  I installed VS20008  and SP1 for VS2008. including the x64 compiler tools and run-times  When I try to build executables in VS for Intel-64 it works fine.  Building Win32 executables it can't find LIBCMT.LIB.  I see that it isn't in the 9.0/VC/lib directory, although libcmtd.lib is there. 

If I try to build in the IVF CMD environment for Intel-64 it fails when it can't find KERNEL32.LIB. 

Any idea why I'm missing these files?

Thanks,

Dave

Hi everyone,

I am compiling a simple project but there is an error: Access violation writing location 0x0000000000230000. I don't understand it very well. Here is are the sources (x64 build).

--------------------------------------------------------------------------------------------getarg.c (this single file will be a library getarg.lib)

#include <stdio.h>
#define iargc_ for_iargc
#define getarg_ for_getarg

extern int iargc_();

extern void getarg_(short*,char*,short*);

//(int*, char*, int*) doesn't work

void init()

{
char name[256];
short nlen = 0;
printf("%i\n", iargc_());
for (int jj=0; jj < iargc_(); ++jj) {
short ishift = jj;
getarg_(&ishift,name,&nlen);
}
}

-----------------------------------------------------------------------------Main.f90 (will be linked to getarg.lib and use init)

program Main

implicit none

call init

end program Main

The Solution can be compiled and linked (/iface:cref) without and problem. But when I run it (e.g. Main.exe aa bb cc, I got the Access Violation error. I have to make it this way since  a similar thing is done in a libaray. iargc (for_iargc()) works great but getarg is somehow different.

Any comment will be appreciated!