The debugger does support REAL*8 and REAL*16 variables. I'll take a look at your other thread on Monday.

I haven't run your code (don't have all the files), however in lookint at test08.f90

real*8 x(6,20)
read(*,*)
do iang2=0,huge(iang2) ! circles march CCW
do iang=1,6 ! hexagonal array
x(1,iang)=40D0*cosd(60.D0*iang+0.1D0*iang2)
x(2,iang)=40D0*sind(60.D0*iang+0.1D0*iang2)
enddo ! iang

x(3:6,7:20) is uninitialized data

In looking at plot.f90

! store pos to be erased later
yl(:nstate,iplan)=y(:nstate,iplan)

You are copying uninitialized data.

As to if this is an issue or not (e.g. what happens when uninitialize data is NaN) I cannot say.

To fix this programming faux pas

real*8 x(6,20)

x = 0.0D0 ! wipe array
read(*,*)

Jim Dempsey

Use a ZIP file to upload multiple files or those with file types not accepted. I will ask that .inc be added to the list, but there isn't as universal a convention for Fortran includes as there is for C.

Probably unrelated to any debugger issues, but...

Quote:

I already knew about the "uninitialized data." An array usually is set up with all zeros by default, right?

No, unless you are relying on some compiler extension.

Some choices made by the compiler writers may result in zero initialisation of things being a repeatable consequence of their particular implementation, but you shouldn't rely on that for robust and portable code. Change compiler, compiler version, day of the week or underpants, and things may turn out different.

Quote:

I made the CC array STATIC.

Should you be using SAVE instead of STATIC?

SAVE is the standard way of saying "please retain values between calls".

STATIC is an extension (that I'll admit I've never used) that nominates where the variable is to be stored (that choice may then give the appearance that the variables have been saved - and in a similar manner the appearance that variables have been zero initialised).

It's trivial to specify both the save attribute and zero initialise in a standard conforming way...

real(8) :: cc(2,20) = 0.0

Because the initialisation ("= 0.0") appears, the cc array above is automatically given the save attribute by the rules of the language (you can pop an explicit SAVE attribute in there for that variable too, for clarity, if you want).

The compiler's default is "auto-scalar", which means that scalar variables are allocated "on the stack", so they don't retain values across calls, but arrays are allocated statically so that they tend to do so. You should not depend on this. Use of options such as OpenMP, or RECURSIVE changes this behavior. If your code requires values to retain their definition across calls, use SAVE. Some older compilers, including CVF, made all variables SAVE by default, but Intel Fortran does not.

There's a difference between an "accidental" consequence of how the compiler implements things, and what you specify (via your program's source) must happen. If I modify your program slightly (introduce another call)...

      program test09

      do ! forever

        call somethingelse

        call sub1

      enddo

      end program
      subroutine sub1()

      real*8 a(2,20)

      real (kind=8),static::b(2,20)=3.D0

      real (kind=8),SAVE  ::c(2,20)=5.D0

      print *,a(2,2),b(2,4),c(1,6)

      read (*,*)

      a(2,2)=a(2,2)+0.1D0

      b(2,4)=b(2,4)+0.25D0

      c(1,6)=c(1,6)+0.125D0

      end
      subroutine somethingelse

      end subroutine somethingelse

and compile with slightly different settings...

[U:projectsFortranMiscFortranMisc]

>ifort /Qopenmp /Od test09.f90

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.
Microsoft (R) Incremental Linker Version 10.00.40219.01

Copyright (C) Microsoft Corporation.  All rights reserved.
-out:test09.exe

-subsystem:console

-defaultlib:libiomp5md.lib

-nodefaultlib:vcomp.lib

-nodefaultlib:vcompd.lib

test09.obj
[U:projectsFortranMiscFortranMisc]

>test09.exe

  9.346029998203773E-307   3.00000000000000        5.00000000000000
  0.100000000000000        3.25000000000000        5.12500000000000

forrtl: error (200): program aborting due to control-C event
[U:projectsFortranMiscFortranMisc]

>test09.exe

  1.735400485756454E+261   3.00000000000000        5.00000000000000
  1.735400485756454E+261   3.25000000000000        5.12500000000000

forrtl: error (200): program aborting due to control-C event

Clearly a isn't being initialised to zero - it is just picking up some (random!) garbage present in memory.

(Note both b and c are SAVEd - c explicitly while b has an initialiser which automatically implies SAVE.)

IanH, great example.

FWIW - What you see (relating to assumed initialization) in Debug Build is not necessarily what you see in Release Build. e.g. Uninitialized variable checks initialize variables and flags to values for test.

Jim Dempsey

I would suggest that you want to use PARAMETER constants instead of variables, SAVE or otherwise.

You are correct that there is a difference between SAVE and initialized. Giving a variable the SAVE attribute does not initialize it - SAVE means that whatever definition status a local variable had when the routine exited, that same status is in effect when the routine is reentered.

Do not make the mistake in assuming that SAVEd variables are initialized by default, even if you see what you think are initial values (such as zero.) You may be observing a side-effect of implementation, not something by design.