INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Jobs

gfortran ignores common

gfortran ignores common

(OP)

CODE --> 95

 

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 ?

RE: gfortran ignores common

The common block is missing from the subroutine.

RE: gfortran ignores common

(OP)
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

RE: gfortran ignores common

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

RE: gfortran ignores common

(OP)
" 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.

RE: gfortran ignores common

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

RE: gfortran ignores common

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

RE: gfortran ignores common

(OP)
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

RE: gfortran ignores common

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

CODE

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

RE: gfortran ignores common

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

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members!

Resources

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close