This illustrates the problem more easily. It's a simple test case running the subroutine that gave
the problems I mentioned.

Oddly enough, this same test case runs FINE with an earlier build of Fortran I have on another computer.
Now if you set a breakpoint at the beginning of the PLOT routine, and have it run that first DO LOOP
ending at about line 29, set the breakpoint there, and take a look at the values of the CC array. I saw them as garbage.
Obviously they should be between -1 and 1, since its a TRIG routine that generated them.

That DO loop should only run once, but the CC array values are all wrong. Probably why the
circles don't draw properly.

I am wondering if something subtle was done to the newer build I have build 13.05, I believe on this computer.

Other REAL*8 values look OK however.
Then the graphics program does not draw the circles every 64th call,, it only draws the dots.

Am I doing something subtly wrong?
But as I said earlier, the program runs FINE with an earlier Fortran package.
I could NOT upload the INCLUDE file. It has in it:
parameter nstate=6,maxplan=8, nplan=6

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

But that isn't the problem I am addressing here.
The code I am inserting at lines 24-29 only gets executed ONCE, when the routine is first called.
I didn't want to set up the CC array every time, for obvious reasons.
It does not set up that array properly, and when I display the values, those are junk.
I will put in a print statement, to see if the values are really junk. They are supposed
to be points on a unit circle. The POLYGON_W routine apparently is not getting the right numbers.
As I said before, in an earlier build of FORTRAN, the numbers are OK. Could it be the
library routine itself?

I should not have to say USE IFQWIN in the CONTAINed routine, right? It knows where to
"find" the array, I assume.

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.

Actually, I found a way to FIX the problem - - -
I made the CC array STATIC.
Apparently the compiler DOES NOT KEEP the same storage elements
around as I assumed, when the routine is called again.
I don't see why that issue didn't come up with an earlier Fortran version, though.
I still get garbage values displayed from the debugger. I will try to make the
CIRC array static also, even though it gets regenerated every time.
But still I get junk values from the debugger

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).

I generated a simple test case (see upload) the illustrates all three types:
I observed that:
(1) The array A starts off with all zeros, even when I don't specify it.
(2) all three arrays (A,B,C) save their values between subroutine calls
run this, you'll see what I mean - - -

So it isn't clear to me that the SAVE attribute really has any useful purpose
Or maybe it does for single value quantities, as opposed to arrays?
I added two other variables D1 and D2. The value of D2 gets saves between calls, even when I don't specify that,
but D1 does NOT get saved. It is exactly the same each time, although it's garbage every time.

Attachments:

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)...

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.

But isn't there a difference between something which is INITIALIZED and something which is SAVED?
You might want the subroutine to be able to access a set of constants which are available every time
it's called, rather that just saving updated values.

In other words the SAME SET of constants each time it's called.
Example:
real (kind=8)::A(3,2)=(1.5,2.3,-1.9,3.4,5.4,6.5)
Or would I use slashes rather than ()?
Now maybe my program would want to start with these numbers every time it's called - - -
Even though they are modified later on.
So I didn't put SAVE.

It would be nice to have a comprehensive article about this,
with copious examples.

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.