This does not appear to be supported.

PROGRAM Main

    INTEGER :: x

    BLOCK

        VOLATILE :: x

        x = 0

    END BLOCK

END PROGRAM Main

gerbil.f90(3): error #5082: Syntax error, found END-OF-STATEMENT when expecting one of: DATA

    BLOCK

---------^

etc.

I'm attempting to use the debugger for the first time, and I'm having trouble. I don't know if it's a simple problem, like improper configuration of my project, or if it is indicative of some kind of programming error. My compiled code runs from the Windows command line, for whatever that might be worth.

All the messages I'm getting are all in reference to .dll files. Some of them point out that the "Binary was not built with debug information" and other say, "Cannot find or open the PDB file". None of these .dlls are ones that I built, so I have no source code for any of them.

Is there an obvious reason for this, such as the debugger not liking .dlls, or is it more likely something else?

Here's the output I get when I Start Debugging:

'<myProject>.exe': Loaded 'C:\<myProjectDirectory>\<myProject>\<myProject>\Debug\<myProject>.exe', Symbols loaded.

'<myProject>.exe': Loaded 'C:\Windows\SysWOW64\ntdll.dll', Cannot find or open the PDB file

'<myProject>.exe': Loaded 'C:\Windows\SysWOW64\kernel32.dll', Cannot find or open the PDB file

'<myProject>.exe': Loaded 'C:\Windows\SysWOW64\KernelBase.dll', Cannot find or open the PDB file

'<myProject>.exe': Loaded 'C:\<myProjectDirectory>\<myProject>\<myProject>\Debug\<third-party>.dll', Binary was not built with debug information.

'<myProject>.exe': Loaded 'C:\Windows\SysWOW64\imagehlp.dll', Cannot find or open the PDB file

'<myProject>.exe': Loaded 'C:\Windows\SysWOW64\msvcrt.dll', Cannot find or open the PDB file

'<myProject>.exe': Loaded 'C:\Windows\SysWOW64\advapi32.dll', Cannot find or open the PDB file

'<myProject>.exe': Loaded 'C:\Windows\SysWOW64\sechost.dll', Cannot find or open the PDB file

'<myProject>.exe': Loaded 'C:\Windows\SysWOW64\rpcrt4.dll', Cannot find or open the PDB file

'<myProject>.exe': Loaded 'C:\Windows\SysWOW64\sspicli.dll', Cannot find or open the PDB file

'<myProject>.exe': Loaded 'C:\Windows\SysWOW64\cryptbase.dll', Cannot find or open the PDB file

'<myProject>.exe': Loaded 'C:\Program Files (x86)\Intel\Composer XE 2013 SP1\redist\ia32\compiler\1033\ifcore_msg.dll', Binary was not built with debug information.

'<myProject>.exe': Loaded 'C:\Program Files (x86)\Intel\Composer XE 2013 SP1\redist\ia32\compiler\1033\irc_msg.dll', Binary was not built with debug information.

'<myProject>.exe': Loaded 'C:\Windows\SysWOW64\dbghelp.dll', Cannot find or open the PDB file

<myProject>.exe has triggered a breakpoint

The program '[41540] <myProject>.exe: Native' has exited with code 408 (0x198).

Thanks for any suggestions.

Hi all,

I am pleased to join this very active Intel fortran forum and posting my first issue here.

The problem is related to deallocation of the allocated arrays. The same code works seemingly fine on Mac OS X, but fails to execute successfully on Linux. Herewith I enclose the code which is giving problem. The code is basically for interfacing dstegr, a LAPACK routine.

I debug the code as following:

1) First I set ulimit -s unlimited

2) I compile the code as

ifort lapack_dstegr.f90 test_dstegr.f90 -llapack -lblas -g -traceback -warn all -check all

3) By simple ./a.out, it hangs

4) So I checked with gdb

[Thread debugging using libthread_db enabled]

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

 Linear dimension of the matrix         100

 Program has been run successfully

 Number of eigenvalues:          100

 Selected eigenvalues

  6.473654E-01  3.540588E+00  8.517578E+00  1.550983E+01

Program received signal SIGSEGV, Segmentation fault.

0x00002aaaabe94c6c in __GI___libc_free (mem=0x6c6ca0) at malloc.c:2945

2945    malloc.c: No such file or directory.

I also checked with the gfortran which is suggesting that there is some problem in deallocation of the allocated arrays "w" and "subdiag" in test_dstegr.f90 at 92 and 96 line, respectively. However, I don't see any problem at these place as I have checked that the arrays "w" and "subdiag" are allocated before the deallocations occur. So this problem seems ambiguous for me. I would appreciate very much if some one shed light on this issue. 

I have a console application that is running a calculation and I would like to be able to do certain work like saving unsaved data and properly stopping the calculation if the Windows system is going to log off, shut down or restart.

I would like to be able to do something similar to handling the WM_QUERYENDSESSION message in MFC applications - this message is sent by the system to indicate shutdown or logoff.

What I have in my application now is handling interrupt signals, which looks like this:

interface
  function processBreakSignal ( signum ) ! SIG$INT - CTRL+CSIGNAL
    !dec$ attributes C :: processBreakSignal
    integer(4) :: processBreakSignal
    integer(2) :: signum
  end function
  function processTerminationSignal ( signum ) ! SIG$TERM - Termination request
    !dec$ attributes C :: processTerminationSignal
    integer(4) :: processTerminationSignal
    integer(2) :: signum
  end function
end interface

integer(4) :: status4

status4 = SIGNALQQ ( SIG$INT, processBreakSignal )
status4 = SIGNALQQ ( SIG$TERM, processTerminationSignal )
status4 = SIGNALQQ ( SIG$ABORT, processTerminationSignal )

integer(4) function processBreakSignal ( signum )
  !dec$ attributes C :: processBreakSignal
  integer(2) :: signum
  ...
  processBreakSignal = signum
  return
end

processTerminationSignal is coded in the same way like processBreakSignal.

If my application is running and I press Ctrl+C, everything is OK.

If I press Ctrl+Break, the system (Windows 7 Professional 64-bit) immediately closes my console application's window. I thought Ctrl+C and Ctrl+Break fire the same interrupt type SIG$INT, don't they?

Finally, is any of the interrupt types, e.g. SIG$TERM or SIG$ABORT, supposed to handle system restart/shutdown or logoff? Right now, just like with Ctrl+Break, it does not seems so - logoff or shutdown close the console window immediately.

What can I do to handle system shutdown/restart/logoff?

This is not an Intel compiler problem in itself, but I request users of Intel Fortran and Gfortran on Linux x64 systems to try the Fortran program below and reply with details (version of libc.so, compiler version, OS version) about their system if they see the bug on their system as well.

On certain Linux systems, the code for free() in libc.so.6 reads as follows:

000000000007e9f0 <__libc_free>:
...
   7e9ff:       48 85 ff                test   %rdi,%rdi
   7ea02:       74 6c                   je     7ea70 <__libc_free+0x80>
   7ea04:       48 8b 47 f8             mov    -0x8(%rdi),%rax
   7ea08:       48 8d 77 f0             lea    -0x10(%rdi),%rsi
...
   7ea1b:       48 89 f0                mov    %rsi,%rax
   7ea1e:       48 25 00 00 00 fc       and    $0xfffffffffc000000,%rax
   7ea24:       48 8b 38                mov    (%rax),%rdi            <<<==== crash if %rax =  0

A consequence is that if the address passed to free() as the base of the memory to free has bits 26 and up all unset (i.e., =zero), absolute address zero is going to be read from in the last instruction shown above, and the program will either crash or a trap will be taken.

Here is a Fortran program to expose the bug (please comment out the line with STOP to make the program actually crash).

program test_free_bug

   implicit none
   real, dimension (:), allocatable :: w
   integer :: dim, err, mskadr
   integer*8 :: locw    ! for 64 bit systems; INTEGER will do on 32-bit

   dim = 100
   print *, "Dimension of the array", dim

   allocate(w(dim), stat=err)
   if (err /= 0) print *, "w: allocation request denied"

   locw = LOC(w)
   write(*,'(A,Z16.16)')'Address of w after allocation = 0X',locw

   mskadr=IAND(locw,Z'FC000000')
   if(mskadr.eq.0)stop 'masked address is zero, will crash free() on Linux with libc.'

   if (allocated(w)) deallocate(w, stat=err)
   if (err /= 0) print *, "w: deallocation request denied"

end program test_free_bug

This bug report is an outcome of a recent thread in this forum, see https://software.intel.com/en-us/forums/topic/520165 .

Hi everybody,

I'm trying to find where inside my program appears the first NaN var.  So I created the following function:

logical FUNCTION testanan(var)

implicit none
real(8) var

if (var /= var) then
    print*, 'deu NAN na', var
    TESTANAN=.TRUE.
    READ(*,*)
endif

ENDFUNCTION
                 

I run in debug mode and when the message appears in the screen, I press pause to find out in which line the NaN appears. But when I do that, deadlock happens...

How can I identify where is my first NaN happens?

Regards

I have a code which is using static libraries and now I wanna to add a dynamic dll library to that. When I import the new dll library I receive the following error:

libifcoremt.lib(for_init.obj) : error LNK2005: _for_set_fpe_ already defined in libifcoremd.lib(libifcoremd.dll)

libifcoremt.lib(for_vm.obj) : error LNK2005: _for_allocate already defined in libifcoremd.lib(libifcoremd.dll)

libifcoremt.lib(for_vm.obj) : error LNK2005: _for_alloc_allocatable already defined in libifcoremd.lib(libifcoremd.dll)

libifcoremt.lib(for_vm.obj) : error LNK2005: _for_dealloc_allocatable already defined in libifcoremd.lib(libifcoremd.dll)

libifcoremt.lib(for_vm.obj) : error LNK2005: _for_check_mult_overflow already defined in libifcoremd.lib(libifcoremd.dll)

libifcoremt.lib(for_diags_intel.obj) : error LNK2005: _for_emit_diagnostic already defined in libifcoremd.lib(libifcoremd.dll)

libifcoremt.lib(for_reentrancy.obj) : error LNK2005: _for_set_reentrancy already defined in libifcoremd.lib(libifcoremd.dll)

libifcoremt.lib(for_close.obj) : error LNK2005: _for_close already defined in libifcoremd.lib(libifcoremd.dll)

libifcoremt.lib(for_open.obj) : error LNK2005: _for_open already defined in libifcoremd.lib(libifcoremd.dll)

libifcoremt.lib(for_wseq.obj) : error LNK2005: _for_write_seq already defined in libifcoremd.lib(libifcoremd.dll)

libifcoremt.lib(for_wseq.obj) : error LNK2005: _for_write_seq_xmit already defined in libifcoremd.lib(libifcoremd.dll)

newnames.obj : error LNK2019: unresolved external symbol __imp__DLL_SETSEED@0 referenced in function _MAIN__

for runtime library option I have checked all the options (multithreaded dll, multithreaded, debug multithreaded, debug multithreaded dll, ...), however the problem has not been solved.

Can anybody help me?

Hi, I am converting some legacy fortran code into openmp version. It uses some external functions like

interface

  function rotTens(x,mat)

  real,intent(in)::x(6),mat(3,3)

  real:: rotTens(6)

  end function

end interface

...

!$omp parallel do &

!$omp default(shared)&

!$omp private(I,j,x,y) &

do I=1, n_time

do j=1, neighbor(I)

   y = rotTens(x,mat)

end do

end do

Results are same up to threads 1~3, but 4 or more threads yield different answer every time (changes every time). The change is very small but noticeable (~0.01%). I checked variables of the function and it seems that memory is corrupted(? inside of the function, rotTens = x*mat  but printing rotTens and x*mat show different values). Such corruption is not found in all loops but in small fractions, randomly. In other words, error or corruption comes from non-consistent points. Very hard to predict or fix.

I haven't had this kind of experience before, and could anyone give me some advice or tip? The OpenMP loop is quite lengthy  (a few hundreds lines) . I tested ifort 13/14.1 and both yielded similar results. Any comments will be greatly appreciated.

Thanks,

ByoungSeon

I ran into an interesting change from OpenMP 3.1 to 4.0: ATOMIC variables can no longer be ALLOCATABLE (I've asked on an OpenMP forum why this change was made).  This broke my code when I compiled it under gfortran 4.9.1, but it still works with 14.0.3, so assume Intel Fortran does not (luckily for me) implement the full OpenMP 4.0 standard yet.  I wish they had kept the old behavior with a bare ATOMIC directive and implemented the new behavior with the ATOMIC UPDATE form.  Probably to late to complain now.

The code below fails with segmentation error unless the arrays "f" and "e" have the same dimension using the Intel Fortran compiler. Appreciate if someone can explain why the array "f" cannot be larger (and much larger) than the array "e." Gfortran does not fail.

---

program test_arrfunc1

! Test of array-valued functions, Aug. 12, 2014.

! Red Hat Enterprise Linux Workstation release 6.5 (Santiago)

! $ ifort --version

! ifort (IFORT) 14.0.1 20131008

! Copyright (C) 1985-2013 Intel Corporation.  All rights reserved.

! $ ifort -traceback test_arrfunc1.f90

! $ ./a.out

! forrtl: severe (174): SIGSEGV, segmentation fault occurred

! Image              PC                Routine            Line        Source             

! a.out              000000000046E269  Unknown               Unknown  Unknown

! a.out              000000000046CBE0  Unknown               Unknown  Unknown

! a.out              000000000043E872  Unknown               Unknown  Unknown

! a.out              0000000000423363  Unknown               Unknown  Unknown

! a.out              0000000000402FCB  Unknown               Unknown  Unknown

! libpthread.so.0    0000003E9440F710  Unknown               Unknown  Unknown

! a.out              0000000000476286  Unknown               Unknown  Unknown

! a.out              0000000000402CCA  MAIN__                     46  test_arrfunc1.f90

! a.out              0000000000402BA6  Unknown               Unknown  Unknown

! libc.so.6          0000003E9401ED1D  Unknown               Unknown  Unknown

! a.out              0000000000402A99  Unknown               Unknown  Unknown

!

! Works when "real(kind=dp),dimension(np) :: f" is defined. Output is here:

! $ ./a.out

! f   1.00000000000000        2.00000000000000        3.00000000000000     

!    4.00000000000000        5.00000000000000        6.00000000000000     

!    7.00000000000000        8.00000000000000        9.00000000000000     

!    10.0000000000000     

  implicit none

  integer,parameter :: i4b = selected_int_kind(9)

  integer,parameter :: dp = kind(0.0d0)

  integer(kind=i4b) :: i

  integer(kind=i4b),parameter :: np = 10

  real(kind=dp),dimension(np) :: e

!  real(kind=dp),dimension(np) :: f     ! works

  real(kind=dp),dimension(10000) :: f   ! fails

  e = (/(i, i=1,np)/)   ! generate some values

  ! call array-valued function

  f = arrfunc1(e,np)

  print *,'f',f(1:np)

        

  contains

    function arrfunc1(e,np)

    implicit none

    integer,parameter :: i4b = selected_int_kind(9)

    integer,parameter :: dp = kind(0.0d0)

    integer(kind=i4b),intent(in) :: np

    real(kind=dp),dimension(np),intent(in) :: e

    real(kind=dp),dimension(np) :: arrfunc1

    arrfunc1 = e

    end function arrfunc1

end program test_arrfunc1

---

Thanks!

Does anyone have a nice way to get the path the user's "My Documents" directory from Intel Fortran?

Hi, let me premise by saying I'm ling-retard illiterate. I understand how things work but I am not familiar with the lingo of compilers, and software and hence am having a lot of problems. Let me write down the problem first,

Trying to compile a blank program,

[code]

program test

    implicit none

    include 'mpif.h'

    integer, parameter  :: i    = 16;   ! number of rows

    integer, parameter  :: j    = 16;   ! number of columns

    integer             :: ierror,npe,rnk;

    call mpi_init(ierror);

    call mpi_comm_size(mpi_comm_world,npe,ierror)

    call mpi_comm_rank(mpi_comm_world,rnk,ierror)

    call mpi_finalize(ierror);

end program

[/code]

I use

ifort test.f90

and get the following error.

ifort: error #10037: could not find 'link'

I've tried googling this error without any useful stuff. I don't have visual studios installed and as I understand I can compile code using command line without visual studios. Anyone willing to explain this to me or just point me to something I can read that would help I'd greatly appreciate it.

Longer story, is I just want to write code and compile it on my machine before porting it to HPC systems. I can't compile, test and run code there from bottom up. I'd like to do this on my windows machine, yes hate me I use windows instead of linux or macs. There are no fortran mpi compilers that are free unfortunately for windows, or I haven't been able to find one. Right now I'm running a trial version of the intel cluster hoping that maybe it'll be a solution for me. I can for example use the code::blocks ide to compile fortran open mp code. I don't expect to use the ide with the intel compiler as I don't think that's possible, but if I can use command lines to just compile code to test that it works I'll be very happy. Anyway sorry for being so ignorant but any help is greatly appreciated.

Hi, I am compiling a bunch of .f90 files using the below makefile. The error that I get on using -O2 optimization is posted just below that. Can't figure out where the problem is :/

The makefile is



!---------------------------------------------------



.SUFFIXES: .o .f90

.f90.o:

$(F90) -c $(F90FLAGS) $<

F90 = ifort -warn -WB -C

LD = $(F90)

LIBS = -ldl

PROFILE = -O2

OPTFLAGS = -g

CFLAGS = $(OPTFLAGS) $(PROFILE)

F90FLAGS = $(CFLAGS)

LDFLAGS = 



PROGRAM = fadd2d

F90SRCS = global.f90 main.f90 nrtype.f90 nrutil.f90 remesh_module.f90 \

prep.f90 elem_charles.f90 \

assemb_charles.f90 formakf_charles.f90 gauss.f90 shape.f90 solver.f90 \

post_remesh.f90 proc.f90 volume_solver.f90 pressure_solver.f90 \

rearge.f90 sif.f90 sifaniso.f90 root.f90 kernel1_c.f90 kernel2.f90 \

tstress.f90 tstress1.f90 tstress2.f90 tstress2a.f90 tstress3.f90 \

assemb_tstress.f90 rigidinner4.f90



SRCS = $(F90SRCS) 



OBJS = $(F90SRCS:.f90=.o)



all: $(PROGRAM)



$(PROGRAM): $(OBJS)

$(LD) -o $@ $(LDFLAGS) $(OBJS) $(LIBS)



elem_charles.o: elem_charles.f90 ekc_2.f90 ekd_2_temp.f90 ek_b2.f90 ek_at2.f90 \

eatts2.f90 eattip.f90 eat3.f90 ebts2.f90 ebtip.f90 eb3.f90 \

eat_rigid.f90 eb_rigid.f90

$(F90) -c $(F90FLAGS) elem_charles.f90



#Dec10_09: add prep.f90 to following line to recompile prep.f90

prep.o: prep.f90 setint.f90

$(F90) -c $(F90FLAGS) prep.f90

clean:

rm -f $(OBJS) $(PROGRAM)

rm *.mod

tidy:

rm -f *.BAK *.bak *.CKP *~



undepend:

rm -f $(OBJS:%.o=.%.d) 



spotless: tidy clean undepend



!------------------------------------



And the error message is



!------------------------------------



ifort -warn -WB -C -o fadd2d global.o main.o nrtype.o nrutil.o remesh_module.o prep.o elem_charles.o assemb_charles.o formakf_charles.o gauss.o shape.o solver.o post_remesh.o proc.o volume_solver.o pressure_solver.o rearge.o sif.o sifaniso.o root.o kernel1_c.o kernel2.o tstress.o tstress1.o tstress2.o tstress2a.o tstress3.o assemb_tstress.o rigidinner4.o -ldl

/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crt1.o: In function `_start':

(.text+0x12): undefined reference to `__libc_csu_fini'

/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crt1.o: In function `_start':

(.text+0x19): undefined reference to `__libc_csu_init'

/usr/local/src/intel/fce/10.1.012/lib/libifcore.a(for_aio.o): In function `for_waitid':

for_aio.c.text+0xc65): undefined reference to `dlsym'

for_aio.c.text+0xc89): undefined reference to `dlsym'

for_aio.c.text+0xcad): undefined reference to `dlsym'

for_aio.c.text+0xcd1): undefined reference to `dlsym'

for_aio.c.text+0xcf5): undefined reference to `dlsym'

/usr/local/src/intel/fce/10.1.012/lib/libifcore.a(for_aio.o):for_aio.c.text+0xd19): more undefined references to `dlsym' follow

make: *** [fadd2d] Error 1

The following compiler versions are supported:

• Intel® C++ and Fortran Composer XE 2013 SP1 for Linux* or OS X* (Compiler version 14.0)
• Intel® C++ and Fortran Composer XE 2013 for Linux* or OS X*  (Compiler version 13.0†/13.1)
• Intel® C++ and Fortran Composer XE 2011 for Linux* or OS X*  (Compiler version 12.0†/12.1)
• Intel® C++ Composer XE 2013 SP1 for Windows* (Compiler version 14.0)
• Intel® C++ Composer XE 2013 for Windows*  (Compiler version 13.0†/13.1)
• Intel® C++ Composer XE 2011 for Windows*  (Compiler version 12.0†/12.1)
• Intel® Visual Fortran Composer XE 2013 SP1 for Windows* (Compiler version 14.0)
• Intel® Visual Fortran Composer XE 2013 for Windows*  (Compiler version 13.0†/13.1)
• Intel® Visual Fortran Composer XE 2011 for Windows*  (Compiler version 12.0†/12.1)

The general policy is that the current version and two previous major versions are supported.

Interactive support via Intel® Premier Support is provided for these compiler releases with Commercial or Academic licenses. Older compiler versions are not supported. Typically, bug fixes are provided for the latest version only, unless an explicit support contract for older versions exists. Users of all versions and license types are welcome to post questions in our User Forum.

If you have any questions about this policy, contact Intel® Premier Support.

† Use of these versions is supported, but fixes will be delivered in the associated X.1 release

Is my understanding correct, that the current Beta and the upcoming 15.x release of ifort will support Coarrays on MIC (xeon phi)?

Will the compiler and hardware be able to generate code that can run on the Xeon Phi in “native” mode, rather than “offload” or “symmetric” modes? By native mode, I mean that it will be able to execute on machines like the DOE’s upcoming Cori where each instance of the SPMD code executes entirely on the xeon phi, with multiple instances (if we were talking about MPI rather than CAF, instance = MPI rank) per Xeon Phi.

TIA

Steve, Colleagues,

I  have successfully used OpenMP to create a threaded IA32 version of an executable. The code contains "use omp_lib" since I'm calling a few OpenMP functions.  I note that in the Project Property Pages the "Additional Include Directories" is blank in for both WIN32 and x64 OS targets. Before the current attempt to thread the code, I have been producing IA32 and x64 versions of executables from the same source; I have simply changed the target OS; it has not been necessary to explicitly point to different library places.

Now, with the threaded code, if I do nothing but change target OS from WIN32 to x64 (using the drop-down in VS 2010), then the OpenMP library is not found and I get the following message:

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

I am using VS 2010, and the lasted compiler: XE 14.0.3.202

BTW: if I comment out the "use omp_lib" line of code, I get no error message(s) but neither the compiler nor linker note that incorrect code is being generated. Jim Dempsey has commented on this before in this forum.

Suggestions?

David

Hi,

I am working on compiling some functionnal Win32 code to x64. I am encoutering the following error:

error #7226: An integer pointer variable has been explicitly given a data type that is not the integer type and kind for an address on the current platform.

Here is an example of the code that gives me this problem:

      SUBROUTINE ABCD

      IMPLICIT NONE

      INTEGER*4 i , ij , j , k , kxx , li

      INTEGER pt10

      POINTER (pt10,pt10p)

      RECORD /NRSTRUC10/ pt10p

I am not quite familiar with the use of pointers in fortran... Can you give me a hint on what to look for to fix this issue ?

Thank you

Philippe

I have a code which is using so many modules and now I want to extend it, but I don't want to give the main modules to other developers. As a consequence I decided to make static libraries from the main modules.

First of all, is this a good idea to hide the main part of the code?

Secondly, I tried to write static library projects containing just subroutines and functions and used them easily in the main project. However, for the modules I could not do that. As I know to import a module in a project we should add "use module" in the main project, but when making static library of module, it seems that the module can not be imported by "use" term.

I could not find any reference to explain how to make static library of modules and import that in a project.

Could you please help me to do that, if possible please explain it with example.

Thanks

I have a simulation software that I am part of the development which runs a variety of different model inputs. For one of the model inputs triggers a stackoverflow crash that only occurs in debug mode. Below is what is printed to the command prompt and I have attached an image of what pops up when I run debug within VS. (I apologize for deleting the information pertaining the specific files.)

######################################################

forrtl: severe (170): Program Exception - stack overflow

Image              PC           Routine    Line      Source

PROG_Debug   0000000141A3CB77 

PROG_Debug   00000001405ED7D0 

PROG_Debug   00000001400C4C4A

PROG_Debug   0000000141815D36 

PROG_Debug   0000000141ABA386  Unknown      Unknown  Unknown

PROG_Debug   0000000141A3D1FC  Unknown      Unknown  Unknown

PROG_Debug   0000000141A3D33E  Unknown      Unknown  Unknown

kernel32.dll 00000000770959ED  Unknown      Unknown  Unknown

ntdll.dll    00000000771CC541  Unknown      Unknown  Unknown

######################################################

Looking at the line numbers for the code it crashes on the following FORALL statement

         FORALL(I=1:NROW,J=1:NCOL,K=1:NLAY,ILOC(J,I,K).NE.0)
     +     BUFF(J,I,K)=BUFF(J,I,K)/( DR(J)*DC(I)*(BTM(J,I,LM(K)-1)-BTM(J,I,LM(K))) )

(Note that in this run NROW=150, NCOL=150, NLAY=6, so they are not big arrays and the LM index pointer array is correct)

The indexing is fine and all the variables are fine (used in other parts of the code). When I run the code on release it does not crash, but the variable BUFF is dumped to a file after that FORALL, but that happens as if the FORALL acts like a RETURN statement.

When I change the FORALL to a DO CONCURRENT as follows:

         DO CONCURRENT (I=1:NROW,J=1:NCOL,K=1:NLAY,ILOC(J,I,K).NE.0)
          BUFF(J,I,K)=BUFF(J,I,K)/( DR(J)*DC(I)*(BTM(J,I,LM(K)-1)-BTM(J,I,LM(K))) )
         END DO

The code in debug mode behaves as expected. Is this a bug, or am I missing something with regards to FORALL statements. Should I go through my code and clean out the FORALL in favor of DO CONCURRENT.

Thanks as always.

Hi,  I have a problem and I did not find a solution : I want to use parallelism in the free code  , but a problem occurred in the allocation of arrays: 

PROGRAM LMTART

USE PARA_CONTROL

    use omp_lib

    INTEGER I,J

    real, allocatable, dimension(:) :: a

    PARA_FIRST=.True.

    !$OMP PARALLEL  DEFAULT(firstprivate) 

    !$OMP DO

    DO I = 1, 10

    if(PARA_FIRST) then

    allocate(a(100))

    DO J = 1, 10

    a(j)=j    

    ENDDO

    endif

    write(*,*) (a(J),J=1,10)

    PARA_FIRST=.False.

    ENDDO

    !$OMP END DO

    !$OMP END PARALLEL

   END

It should be noted that : do not  reserved  the table "a" before entering in the  DO  directive