Text deleted as now resolved. 

Hi,

My debugger is not showing most of the variable contents including some local variables, even do loop index.  The "Locals" window shows some local variables but not all.  Interestingly, it is not showing any integer variables.  I don't have any access to the module variables, either.

I've tried VS C++ 2010 SP1 Redistributable Package (X86) as recommended in the Intel Fortran 2015 release note, but it didn't help.  I had the issue with XE2015 but I am still having the same issue with my current setup of:

MS Visual Studio Premium 2013 : Version 12.0.21005.1 REL

Intel Parallel Studio XE2016 Composer Edition for Fortran Windows* Package ID: w_comp_lib_2016.0.110

Please help.

I have a complicated Fortran program with multiple modules in many files. When I try to compile with either v14.0 and v15.0 using the -g flag, I segFault on the first line of the program. Removing the -g flag fixes the problem and there are no problems at runtime.

Some sample code is below

program Main
implicit none

REAL, PARAMETER :: Pi = 3.14159265359
integer,parameter :: ND = 2

real, parameter :: RL = 1.0E-6	!Boundary radius
real, parameter :: HN = 5.0E-6	!Length of included needle
real, parameter :: HL = 2.0E-6	!Tip height

real, parameter :: LTT = 3E-6	!Tip-to-tip distance

real, parameter :: RU = 0.5E-6	!Boundary radius
real, parameter :: HU = 1.5E-6	!feature height

real, parameter :: zLen = HN + HL + LTT + HU

real,parameter,dimension(ND) ::	Length = (/ 20E-6, zLen /)			!computational domain size (r,z)

! Grid Spacing
real, parameter, dimension(ND) :: delta = (/ 1.0E-8	, 1.0E-8 /)
integer, PARAMETER, dimension(ND) :: cells = Length / delta

real,parameter :: VApplied = -150

REAL, PARAMETER :: cathode_temperature = 1473.14		!Cathode Temperature [K]
REAL, parameter :: anode_temperature = 973.14			!Anode Temperature [K]
real :: Cathode_Voltage, Anode_Voltage

REAL, dimension(0:cells(1), 0:cells(2)) :: phi
REAL, dimension(0:cells(1), 0:cells(2)) :: temperature				!grid-wise gas temperature

integer:: i,j

phi = 0.0
temperature = 0.0

	Cathode_Voltage = VApplied
	Anode_Voltage = 0

forall(i=0:Cells(1), j=0:Cells(2), j <= nint(lowerBoundary(i * delta(1)) / delta(2)))
	phi(i,j) = Cathode_Voltage
	temperature(i,j) = cathode_temperature
end forall

forall(i=0:Cells(1), j=0:Cells(2), j >= nint(upperBoundary(i * delta(1)) / delta(2)))
	phi(i,j) = Anode_Voltage
	temperature(i,j) = anode_temperature
end forall

!forall(i=0:Cells(1), j=0:Cells(2), (j > nint(lowerBoundary(i * delta(1)) / delta(2))) .and. (j < nint(upperBoundary(i * delta(1)) / delta(2))))
!	phi(i,j) = Cathode_Voltage + (Anode_Voltage - Cathode_Voltage) * ((delta(2) * j - lowerBoundary(i * delta(1)) ) / ( upperBoundary(i * delta(1)) - lowerBoundary(i * delta(1)) ))
!	temperature(i,j) = cathode_temperature + (anode_temperature - cathode_temperature) * ((delta(2) * j - lowerBoundary(i * delta(1)) ) / ( upperBoundary(i * delta(1)) - lowerBoundary(i * delta(1)) ))
!end forall

contains
	pure function LowerRegion(r) result(k)

	implicit none
		real,intent(in) :: r
		integer :: k

		if (r < 0) then
			k = 0
		elseif (r < RL) then
			k = 1
		elseif (r >= RL) then
			k = 2
		elseif (r > R) then
			k = 3
		endif
	end function LowerRegion

	pure function UpperRegion(r) result(k)

	implicit none
		real,intent(in) :: r
		integer :: k

		if (r < 0) then
			k = 0
		elseif (r < RU) then
			k = 1
		elseif (r >= RU) then
			k = 2
		elseif (r > R) then
			k = 3
		endif
	end function UpperRegion


!!!!!!!!!!!! Define geometry for regions radially !!!!!!!!!!!!!!!!!!
	pure function lowerBoundary(r) result(z)

	implicit none
		real,intent(in) :: r
		real :: z

		if (LowerRegion(r) == 1) then
			z = HN + HL * (1.0 - (r / RL))
		elseif (LowerRegion(r) == 2) then
			z = 0.0
		endif
	!end function lowerBoundary_Scalar
	end function lowerBoundary

	pure function upperBoundary(r) result(z)

	implicit none
		real,intent(in) :: r
		real :: z

		if (UpperRegion(r) == 1) then
			z = zLen - HU * (1.0 - (r / RU))
		elseif (UpperRegion(r) == 2) then
			z = zLen
		end if
	end function upperBoundary

end program Main

Hi,

I am trying to understand if my interpretation of nested WHERE blocks is incorrect or if the compiler is producing an incorrect execution.

I encountered numerical floating point exceptions in a large program because of the execution of LOG10(0.D00) inside a nested WHERE block, even though execution of array arguments with values <= 0.0D0 should be prevented by a mask in the outer WHERE block.

The following test code reproduces the problem when the compiler flag /fpe:0 is set for floating point exception handling.

!** A simple program to test issues with nested WHERE constructs **
PROGRAM NestedWHERE

IMPLICIT NONE

INTEGER(4) :: j
INTEGER(4), PARAMETER :: n = 4, k = 100
REAL(8),DIMENSION(n) :: arrayA, arrayB, arrayC, arrayD
!-------------------------------------------------------

arrayA = [1.0D0, 2.0D0, 0.0D0, 4.0D4]
arrayB = [1.0D0, 2.0D-2, 0.0D0, 4.0D-6]

!Nested WHERE block
WHERE (arrayA(1:n) > 0.0D0)
    WHERE (ABS(LOG10(arrayA(1:n))) + ABS(LOG10(arrayB(1:n))) < 300.0D0) !issue: LOG10 seems to be executed for all array elements (including elements where arrayA == 0.0D0). Why is the mask (of the outer WHERE) not applied?
        arrayC(1:n) = arrayB(1:n)/arrayA(1:n)
    ELSEWHERE
        arrayC(1:n) = 8.0D-4
    ENDWHERE
ELSEWHERE
    arrayC(1:n) = 1.111111111
ENDWHERE

!The procedure of the above nested WHERE block expressed by DO-loop and nested IF-END IF blocks (works as expected).
DO j = 1,n
    IF (arrayA(j) > 0.0D0) THEN
        IF (ABS(LOG10(arrayA(j))) + ABS(LOG10(arrayB(j))) < 300.0D0) THEN
            arrayD(j) = arrayB(j)/arrayA(j)
        ELSE
            arrayD(j) = 8.0D-4
        ENDIF
    ELSE
        arrayD(j) = 1.111111111
    ENDIF
ENDDO !J

WRITE(*,'(A23)') "  arrayC,       arrayD "
DO j = 1,n
    WRITE(*,'(2(ES12.4,2x))') arrayC(j), arrayD(j)
ENDDO
WRITE(*,*) ""
WRITE(*,*) "... done."
READ(*,*)

END PROGRAM

I use the Intel(R) Visual Fortran Compiler 16.0.0.110 [IA-32], in MS Visual Studio 2010 on Windows 7.

The ifort command line used is: 
/nologo /debug:full /Od /warn:interfaces /fpe:0 /fp:source /module:"Debug\\" /object:"Debug\\" /Fd"Debug\vc100.pdb" /traceback /check:bounds /check:stack /libs:static /threads /dbglibs /c

The following is an excerpt of the call stack at the point of floating point exception:
     TestNestedWHERE.exe!___libm_log10_w7()  + 0x226 bytes    
    TestNestedWHERE.exe!NESTEDWHERE()  Line 15 + 0x45 bytes    Fortran

I am not sure if my use of nested WHERE statements in this case is incorrect (even though both ABS and LOG10 are elemental intrinsic functions) or if it is supposed to work according to the Fortran standard.

Andi

I found out this unexpected behavior of temporary array when tracing down the root cause of a stack overflow.

In a subroutine, when multi-dimensional dummy arrays with explicit size are declared with the exponentiation operator ** (except in the last dimension), almost any operation in this subroutine that involves section of this array would create a temporary array, even if the section is obviously contiguous ( extreme case being x(:,:) ). Such temporary arrays are not created if the array size is declared using multiplication (n*n instead of n^2, or of higher power)

The following is an example:

program main
    implicit none
    real(8) x(4,2)

    call sub(x,2)
end program main

subroutine sub(x,n)
    implicit none
    integer,intent(in) :: n
    real(8),intent(in) :: x(n**2,2)   ! change to x(n*n,2) and everything's fine

    print*, x(:,:)      ! obviously contiguous, but a temporary array is created nonetheless.
end subroutine sub

Is this behavior a compiler bug or is there some deeper reason to this that I'm not aware of? Help appreciated.

I checked temporary array creation using the -check arg_temp_created compiler option. I am using  ifort version 16.0.0, on a UNIX system computing cluster at my institution.

I'm trying to vectorize this loop using !$OMP SIMD instruction:

!$OMP SIMD private(drx, dry, drz, dist, delta_i_sum_Wab) reduction(+:i_sum_Wab)
 
         loop_j2_count: do kk=1,npart_cell

                                                
            call add_particle%distance(particle_in_cell(kk), container_size,2.*block%global%h, dist, drx, dry, drz)
       
            call particle_interaction(add_particle, particle_in_cell(kk),visc_dt,dist, drx,dry,drz,&
                                           block%global%cs0,block%global%p_backGround,block%global%rho0,block%global%const_ker,block%global%viscos_val, block%global%csi,.false., &
                                           delta_i_ax, delta_i_ay, delta_i_az, delta_i_ar, delta_i_deltax, delta_i_deltay, delta_i_deltaz, delta_i_div_pos, delta_i_sum_Wab, delta_i_n_neibou, shifting_enabled)
#ifdef SUMWAB
                i_sum_Wab=i_sum_Wab+delta_i_sum_Wab
#endif
                

                                    
          enddo loop_j2_count
!$OMP END SIMD

the problem seems to be the type-bound procedure distance which is defined as follows:

  pure subroutine distance(vec1,vec2,container_size, cell_size, dist, drx, dry, drz)

  implicit none

  class(Type_particle_or), intent(in):: vec1
  class(Type_particle_or), intent(in):: vec2
  real(R8P), intent(in) :: container_size(3)
  real(R_P), intent(in) :: cell_size
  real(R8P), intent(out) :: dist
  real(R8P), intent(out) :: drx, dry, drz
  logical :: plot

  drx=vec1%xp-vec2%xp
  dry=vec1%yp-vec2%yp
  drz=vec1%zp-vec2%zp
   
  plot=.false.
  call periodicityCorrection(drx,container_size(1),cell_size, plot)
  call periodicityCorrection(dry,container_size(2),cell_size, plot)
  call periodicityCorrection(drz,container_size(3),cell_size, plot)
 
  dist=sqrt(drx*drx+dry*dry+drz*drz)

  end subroutine distance
 
  this distance subroutine is bound to the following type:
 
  type, public:: Type_particle_or

  real(R8P)::                            xp = 0._R8P  !< x coords.
  real(R8P)::                            yp = 0._R8P  !< y coords.
  real(R8P)::                            zp = 0._R8P  !< z coords.
  real(R_P)::                            up = 0._R_P  !< v_x
  real(R_P)::                            vp = 0._R_P  !< v_y
  real(R_P)::                            wp = 0._R_P  !< v_z
  real(R_P)::                            pm = 0._R_P  !< mass
  real(R_P)::                            rhop = 0._R_P  !< density
  real(R_P)::                            p  = 0._R_P  !< pressure
  real(R_P)::                            hp = 0._R_P  !< smoothing length
   
  integer(I_P) ::                        i=0_I_P

  contains

  procedure :: assign_particle => assign_particle_or
  procedure :: modify_size_particle_or
  procedure :: plot_particle
  procedure, public :: distance
 
  end type Type_particle_or
 
 Looking at the optimization report file produced by the compiler with flags -qopt-report=5 -qopt-report-phase=all it seems that the compiler is not able to inline type bound procedures and this creates problems when I try to vectorize the code.
 
  thank you very much for your help

Hi
I wanted to compile a code with MPICH 3.1 but I get the error:

/opt/intel/compilers_and_libraries_2016.0.109/linux/compiler/lib/intel64/libifport.so.5: undefined reference to `for_ifcore_version'

I have the Intel Parallel Studio XE Composer Edition for Fortran and C++ (Linux) (parallel_studio_xe_2016.0.047) installed.

and the .bashrc has the environment variables:

source /opt/intel/compilers_and_libraries/linux/bin/compilervars.sh -arch intel64 -platform linux

LD_LIBRARY_PATH="/home/mohammed/mpich3/bin:$LD_LIBRARY_PATH"
export LD_LIBRARY_PATH

and when I test the ifort and MPI I got :

:~$ which ifort
/opt/intel/compilers_and_libraries_2016.0.109/linux/bin/intel64/ifort
:~$ ifort -v
ifort version 16.0.0
:~$ which mpicc
/home/mohammed/mpich3/bin/mpicc
:~$ which mpiexec
/opt/intel/compilers_and_libraries_2016.0.109/linux/mpi/intel64/bin/mpiexec
any suggestions

thanks

forrtl: severe (67): input statement requires too much data, unit 13, file /gpfs4/home/alodh/OUTPUT/SNOW_DATA/Surf_SnowLat.dat
Image              PC                Routine            Line        Source
SurfProg_Snow.exe  00000000004BF720  Unknown               Unknown  Unknown
SurfProg_Snow.exe  00000000004BD005  Unknown               Unknown  Unknown
SurfProg_Snow.exe  000000000041808D  surf_snow_latlong          87  Surf_Snow_LatLonGrid.f90
SurfProg_Snow.exe  0000000000410732  MAIN__                    384  SurfProg_Snow.f90
SurfProg_Snow.exe  000000000040DBF6  Unknown               Unknown  Unknown
libc.so.6          00002AC427119CDD  Unknown               Unknown  Unknown
SurfProg_Snow.exe  000000000040DAE9  Unknown               Unknown  Unknown

Hello,

I have noticed this problem before with ifort, but never had a solution. Basically, I have a fairly large (modern) fortran code, which is crashing. So in order to diagnose what's causing the crash, I compiled it with the command line

ifort -fPIC -fp-model strict -fomit-frame-pointer -m64 -warn align -r8 -openmp -O2 -g -traceback -check bounds -check format -check pointers -check stack -check uninit -fpe0 -ftrapuv -fp-stack-check -gen-interfaces -warn interfaces

i.e., I put in all check and debug flags I knew. This compiled executable does give me a slightly more informative message on a crash:

forrtl: severe (408): fort: (7): Attempt to use pointer LRATE when it is not associated with a target

but it still doesn't give me a backtrace. The entity 'Lrate' occurs at many places in my code, so without a back trace it's kind of hard to figure out where the code is crashing. Is there anything else I can do to produce a backtrace?

Thanks,

Sourish

I am converting a C++/Fortran application from 32 bit to 64 bit Windows and need to call a Fortran subroutine with no arguments from c++.  This works fine in 32 bit but in 64 bit I receive an error:

LNK2019: unresolved external symbol wtest referenced in function main

The Fortran is linked as a static library and the C++ is obviously the main routine.  I am using defaults for calling methods (which I think is __cdecl under 64 bit).  I have produced the assembly listings and everything looks fine there, ie. both modules are using the same symbol wtest for the Fortran subroutine.  In 32 bit both assembly's prepend an underscore to wtest but it works in that environment.

Using VS 2012 Update 4 and Fortran XE 2015 (Package ID: w_fcompxe_2015.2.179)

Here is the Fortran:

      subroutine WTEST() BIND(C,NAME='wtest')
      return
      end subroutine WTEST

Here is the C++ code:

extern "C" void wtest();

int __cdecl main(int argc, char *argv[])
{
	wtest();
}

I know this topic has been beaten to death over the years and I have looked at/tried many of the suggestions. Again they work in 32 bit but not 64 bit.  I'm sure I am missing something real stupid/obvious so apologies in advance.

Thanks!

So, just before I submit this I try one more thing and now I'm going to answer my own question.  It was real stupid/obvious:  the x64 config puts the Fortran static library in a different folder so I was linking to the wrong thing.  Duh ... maybe this will help someone else.  I don't want to admit to how many hours I've spent on this!

While reading through a rather large text file (~46 Gb), a little less than halfway through the snippet of code shown below crashes.  The variable IFTLFMT is a flag for indicating if the file being read is binary (IFTLFMT=0) or formatted text (IFTLFMT=1).  For debugging, IFTLFMT is currently equal to 1, though the code seems to crash when reading the binary equivalent as well.  With IFTLFMT = 1, the BACKSPACE command is called with each loop and I'm suspicious this is where the problem is.

The behavior leading up to the crash is that as the Fortran shown below is looping, it reads the middle line of example text shown below (shown after the fortran code) and on the next loop, instead of reading the next line of text:

SFR   REJ      1    32    16     1     3  0.108565

It reads LABEL,TEXT which appear to be read in OK based on the values they are filled with, but then runs BACKSPACE(INUF) followed by the next READ statement which is where it crashes.  All of the values in the READ statement are filled with 0.00, which clearly are not in the text file.  Thus, I'm wondering if there is a limit on the number of time BACKSPACE can be used?  I would venture a ballpark guess that BACKSPACE has been called somewhere in the neighborhood of 51.3 million times by the time the crash occurs.  

I've also tried removing the BACKSPACE command, but my limited understanding of READ is that it reads an entire line when reading formatted text.  Thus, the code won't continue reading part way through a line, but this is exactly what I need because the second read statement depends on the value of the first entry on the line.  

Code that crashes:

C--READ CONNECTIONS INFORMATION
      DO I=1,NCON
        IF(IFTLFMT.EQ.0) THEN
          READ(INUF) LABEL,TEXT
        ELSEIF(IFTLFMT.EQ.1) THEN
          READ(INUF,*) LABEL,TEXT
          BACKSPACE(INUF)
        ENDIF
C
C--LOOP THROUGH EACH CONNECTION
C
C--IF UZF -> SFR, READ 8 VALUES
        IF(LABEL.EQ.'SFR ') THEN
          IF(IFTLFMT.EQ.0) THEN
            READ(INUF) KK,II,JJ,ISTSG,NREACH,Q
          ELSEIF(IFTLFMT.EQ.1) THEN
            READ(INUF,2) LABEL,TEXT,KK,II,JJ,ISTSG,NREACH,Q
   2        FORMAT(2X,A4,2X,A4,5I6,F)
          ENDIF
          IROUTE(1,I)=1  !1:SFR, 2:LAK, 3:SNK
          IROUTE(2,I)=KK
          IROUTE(3,I)=II
          IROUTE(4,I)=JJ
          IROUTE(5,I)=ISTSG
          IROUTE(6,I)=NREACH
C         Do some more stuff...
        ELSEIF(LABEL.EQ.'LAK ') THEN
C         ...
        ELSEIF(LABEL.EQ.'SNK ') THEN
C         ...
        ENDIF
      ENDDO

 Example of text that is being read:

...
  SFR   GRW      1    32    16     1     2  0.064677
  SFR   REJ      1    32    16     1     2  0.130278
  SFR   GRW      1    32    16     1     3  0.053897  !After this line, the code crashes
  SFR   REJ      1    32    16     1     3  0.108565
  SFR   GRW      1    32    16     1     4  0.053897

...

I want to pass a fixed length string from C++ to Fortran subroutine, and assign it to a string within that subroutine (to be used elsewhere), and am having some difficulty.

Below is the shortened code. 

character(len=10) :: venue

subroutine Initialisation(venue_name)
   character(len=10), intent(in)                               :: venue_name

   !DEC$ ATTRIBUTES DLLEXPORT :: INITIALISATION

   !How do I assign the string here?
   venue = venue_name

end subroutine Initialisation

I have tried with various different ways of doing it, but keep getting runtime errors. With the above example I get "Dummy character variable "VENUE_NAME" has length 10 which is greater than actual variable length -539671288"

Hello Team,

When we run this script

./get_tmpa.sh 2008010106 2008010106

than I am getting following error:

forrtl: severe (36): attempt to access non-existent record, unit 11, file /iitm1/sspm-res/ocn/deepa/gfsletkf/trunk/gfs/run/tmp/gfs-letkf_deepa_exp1_get_tmpa/tmpa.dat
Image PC Routine Line Source
dec_prcp 0000000000446D93 Unknown Unknown Unknown
dec_prcp 0000000000444AD6 Unknown Unknown Unknown
dec_prcp 0000000000403B54 Unknown Unknown Unknown
dec_prcp 0000000000403986 Unknown Unknown Unknown
libc.so.6 0000003C73A1ECDD Unknown Unknown Unknown
dec_prcp 0000000000403879 Unknown Unknown Unknown
mv: cannot stat `fort.90': No such file or directory

I am also attaching script file. Please suggest me.

Thanks,

Pravesh Goyal

For example, simple code:

    program handlesleak
    implicit none
    integer(4)      :: i


    do i=1, 100
        open(1, file = 'test.txt')
            write(1,*) i
        close(1)
    enddo

    end program handlesleak

1. Then compile by Visual Fortran Compiler 16.0, set breakpoint on line "open(...)" and look at with "Windows Task Manager" for number of handles. Number of open handles increases step by step.

2. Ok, now compile by previous Intel(R) Visual Fortran Compiler XE 15.0.2.179 and do the same steps. Number of handles does not increase.

Is it a bug of new compiler? And what to do to prevent leaks handles?

Please, someone could explain me how to get a real data from an edit box, when working with Windows Applications.

Sincerely,

Carlos Santos

I just installed parallel studio 2016. When I open VS and right click on a fortran project, I get the popup in the attached jpg. If I click ok, things work anyway, and I get the right click menu, but I'd like it to go away.

ATTRIBUTES STDCALL

Intel Fortran does not support use of STDCALL with BIND(C) at this time, so if you are interfacing to STDCALL routines (Windows on IA-32 architecture only), you must continue to use the ATTRIBUTES extension, along with ALIAS and DECORATE as required.

https://software.intel.com/en-us/articles/replacing-intel-fortran-attrib...

Err yes you do support it chaps :-)

Hi All

EXEC SQL BEGIN DECLARE SECTION
CHARACTER*(*) X
EXEC SQL END DECLARE SECTION
......................................
......................................

When I try to precompile the above code block I am getting

INTEGER*8 SQLITR
INTEGER*8 SQHSTV(1)
INTEGER*8 SQHSTL(1)
INTEGER*8 SQINDV(1)
......................................
......................................

C EXEC SQL BEGIN DECLARE SECTION
CHARACTER*(*) OAUID
C EXEC SQL END DECLARE SECTION
......................................
.....................................
CALL SQLADR(X, SQHSTV(1))
SQHSTL(1) = (X)
SQINDV(1) = 0
SQHARM(1) = 0
........................................
........................................
But in compilation it shows **The assignment operation or the binary expression operation is invalid for the data types of the two operands. [X]** error.Please guide me to solve this issue.

Hi all,

I installed parallel_studio_xe_2015_update3 on fedora 22 operating system. Although it activated and installed successfully but

it is not working properly. That is when i run a fortran90 code which include some lapack subroutines with this command for compilation-

ifort -mkl example.f90

 It compiled successfully. but as soon as i am going to execute this code with ./a.out, i found that the code stopped suddenly without

completing its loop. For example if my loop is from x=0 to x=7, then it stopped at some random value in between x=0 to x=7.

So i don't know the reason behind this cause. If anybody have any idea about this problem then please help me.

Thanks....

How to link static library .lib to executable program?

Documentation tells about VS2008 and 2010 only.

When I place my .lib file into folder with source files and include it into project compiler gives an error:

error #7002: Error in opening the compiled module file.  Check INCLUDE paths.   [FMZM] 

FMZM - name of module in library I want to use.