gfortran ignores common

[zmth]

integer*1 n1,nps
common n1,nps
n1=5
nps=4
call try
end
subroutine try
print*,"nps",nps,"n1",n1
end

NOw it should printout 4 for nps and 5 for n1 but it does NOT
why ?

 

[xwb]

The common block is missing from the subroutine.

 

[zmth]

ok that was a mistake BUT when do put it in the subroutine it still does NOT
================================
integer*1 n1,nps
common n1,nps
n1=5
nps=4
call try
end
subroutine try
common n1,nps
print*,"nps",nps,"n1",n1
end
======================================
DOES not print 4,5 for nps,n1

 

[xwb]

That is because in the main program n1 and nps are integer*1. In try n1 and nps are defaulting to integer: not integer*1

 

[zmth]

That is because in the main program n1 and nps are integer*1. In try n1 and nps are defaulting to integer: not integer*1 "

Yea I remember that now but if use module
and put the 'use' the module statement then don't have to declare them integer*1 again in the subroutine.

 

[zmth]

Actually there were several errors in the way i rearranged and...
wrote that program
left out a few ' ; ' which i mistakingly deleted to break the lines at end
to write that program in that space as I had longer lines etc/
But the way i wrote it originally it was correct without error.

 

[Beilstwh]

If you feel the need to keep using integer*1 then simply use

integer*1 n1,nps
common n1,nps
n1=5
nps=4
call try
end
subroutine try
integer*1 n1,nps
common n1,nps
print*,"nps",nps,"n1",n1
end

Bill
Lead Application Developer
New York State, USA

 

[zmth]

Re beilstwh

Yes that is what i did. I had just forgotten had to do the integer*1.... deal twice - that is again in the subroutine. Reason I tend to forget this is lately have been using module and in that case one does NOT have to re-declare integer*1 ... BUt only once in the module Eg

module inc
integer*1 n1,nps
end
use inc
nps=4;n1=5
call try
end
subroutine try
use inc
print*,"n1",n1,"nps",nps
end

And n1,nps are both regarded as integer*1 which seems to be another way in which using module is not equivalent to common. I forgot also if on a 32 bit processor in windows 7 using gfortran if it really does save time and storage space by using integer*1 with any possible switches, paramaters after 'gfortran program.f95 -whatever ' Of course not in this simple case but in my actual program where i have lengthy arrays of only integers all of which will always be between -128 thru 127

 

[xwb]

Note that if you are looking at algorithms on the internet, sometimes the authors use or (kind=n), sometimes they use *n. They have different meanings, are not interchangeable and may result in different sizes. Do not mix them.

integer*1 n1, n2
integer(1) n3, n4
integer(kind=1) n5, n6

 

[zmth]

So you are saying
integer*1 n1, n2 ! and
integer(1) n3, n4

Have different meanings or just the

integer(kind=1) n5, n6

Has different meaning ?
Haven't yet looked at algorithms on the internet yet but will try to keep it in mind if do. Another question is for example will I have a problem in the following using 'shared' variable lenb as in the following example . I know I could put
lenb as another parameter in the (....) following ad3n but to save clutter would rather not in general - though
in this example would not be a big deal but in other routines where have many such instances it is much
more convenient NOT to have to put the variables in the list plus having to declare them all integer*1 again etc. it saves
excess writing :

module inc
integer*1 i,i1,i2,i3,ihz,ii,nps
integer*2 lena,lenb
contains
subroutine binomrs(n,id,r)
integer*1 n,i,id,j
j=max(id,n-id)
if(j<=n) then ; r=1
do i=1,n-j
r=r*(n-i+1)/i
enddo
else; r=0
endif ; end
end module inc

use inc
integer*1,allocatable::lisin),liss,
nps=4
allocate(lisin(nps))

do ihz=1,4
i=nps+ihz-1
call binomrs(i,ihz,r)
lena=nint(r)
allocate(liss(nps,lena))
lenb=0
i=1; call ad3n(i,ihz,lisin,liss)
deallocate(liss) ; enddo
end

recursive subroutine ad3n(ii,nn,lisin,liss)
use inc,only:lena,lenb,nps
integer*1 i,ii,k,nn,lisin(nps),liss(nps,lena)
if(ii<nps) then
do i=0,nn
lisin(ii)=i ; k=ii+1
call ad3n(k,nn-i,lisin,liss)
enddo ; else
lisin(nps)=nn
lenb=lenb+1
liss,lenb)=lisin
endif ; end

In the above it gives the correct results.
But reason for asking is that had what i thought was a similar instance of using shared variables with the main
in a recursive subroutine and in the module and it too gave for the most part correct answers but for certain parameters it gave the wrong answer till i had to change it and not share the variables. It is always possible that the compiler just happens to give the correct answers but yet it is not always guaranteed.