Re: Fortran Standard question: COMMON, SAVE and EQUIVALENCE

Larry Gates wrote:
On Sat, 28 Feb 2009 17:48:10 GMT, *** Hendrickson wrote:

Larry Gates wrote:
On Wed, 25 Feb 2009 14:55:29 -0800 (PST), ken.fairfield@xxxxxxxxx wrote:

You've got two similar versions of the program above, maybe
you should trim out one of them. It's possible I'm answering
the correct question about the wrong program. ;)

In the second version, it looks to me like it does. Why
do you think it doesn't? It doesn't in the first example.

This is my eighth version of this program, not counting mistakes. Keeping
the revisions separate on one's computer and for commenting on usenet is
wearing an editor's hat that tends to fit poorly on the writer.
Is the common block ten places when it is called into existence?
Sort of, but that's not the way I look at it. I tend to think
of all the declaratives as one big group. It almost never
matters which order you put the declarations in; so I usually
look at them as a group. Then the common/equivalence in
the main program declares a blank common block of length 149.

I wouldn't say "called into existence"; that, to me, implies that
the declaration in the main program is, somehow, more better
than the others. It really isn't. There are rules for
how common blocks can/must be declared in different procedures;
but one declaration isn't the master one.

Main extends this to 149. When you call the subroutine, doesn't a start
with the beginning of the common block?
I think so, again why don't you think so?

*** Hendrickson

I just ran this with silverfrost and remember why I liked this compiler so
much. Here is the output:


x is 1 2 3 4 5
6
7 8 9
10
y is 1 2 3 4 5
6
7 8 9
10 11 12 13 14 15
16 17 18
19 20 21 22 23 24
25 26 27
28 29 30 31 32 33
34 35 36
37 38 39 40 41 42
43 44 45
46 47 48 49 50 51
52 53 54
55 56 57 58 59 60
61 62 63
64 65 66 67 68 69
70 71 72
73 74 75 76 77 78
79 80 81
82 83 84 85 86 87
88 89 90
91 92 93 94 95 96
97 98 99
23
z is 23 23 23 23 23
23
23 23 23
23 23 23 23 23 23
23 23 23
23 23 23 23 23 23
23 23 23
23 23 23 23 23 23
23 23 23
23 23 23 23 23 23
23 23 23
23 23 23 23 23
heavens is 1 2 3 4 5
6 7 8
9 10 11 12 13 14
15 16 17
18 19 20 21 22 23
24 25 26
27 28 29 30 31 32
33 34 35
36 37 38 39 40 41
42 43 44
45 46 47 48 49 50
51 52 53
54 55 56 57 58 59
60 61 62
63 64 65 66 67 68
69 70 71
72 73 74 75 76 77
78 79 80
81 82 83 84 85 86
87 88 89
90 91 92 93 94 95
96 97 98
99 23 23 23 23 23
23 23 23
23 23
to_betsy is 23 23 23 23 23
23 23 23
23 23 23 23 23 23
23 23 23
23 23 23 23 23 23
23 23 23
23 23 23 23 23 23
23 23 23
23 23 23 23 23
a is 1 2 3 4 5
6
7 8 9
10 11 12 13 14 15
16 17 18
19 20 21 22 23 24
25 26 27
28 29 30 31 32 33
34 35 36
37

Press RETURN to close window . . .

Here is the the source:
implicit integer (a-t)
integer x(10),y(100),z(50)
common x
equivalence (x,y),(y(100),z(1))

x = 333

do i=1, 100
y(i)=i
enddo
z = 23

print *, "x is ", x
print *, "y is ", y
print *, "z is ", z

call sub
call sub2


contains
subroutine sub
common heavens(109),to_betsy(40)

print *, "heavens is ", heavens
print *, "to_betsy is ", to_betsy
end subroutine

subroutine sub2
integer a(37)
common a

print *, "a is ", a
end subroutine

endprogram

! silverfrost's comments:

Compiling and linking file: FreeFormat1.f95
WARNING - Common block "//" was previously defined as size 40 but is now
defined as size 152
WARNING - Common block "//" was previously defined as size 40 but is now
defined as size 600
Creating executable: C:\Documents and Settings\dan\My
Documents\FreeFormat1.EXE

What is silverfrost saying here? Default ints are size 4.

From what you show, it's hard to say. You are "defining" the
common block in several places and [what you show of] the
warnings don't point to a specific thing. The initial
common might have a length of 40 = 4*10. I'd guess the
warning are about the two equivalence sets extending
blank common. Try taking out the two contained
subroutines and see what messages you get. Then, try
uncontaining the subroutines. I don't think there is any
reason for having them as internal subroutines. maybe then
you'll understand the messages.

*** Hendrickson
.