Is common allowed in gfortran

It depends on the file extension.  gfortran works on file extensions.  If it is .f or .for, then it assumes it is f77 so common is allowed.

If it is f90, common is allowed

If it is f95, common is not allowed (if you adhere to the standard)

Save variables are to do with presistence.  It assumes that values remain persistent on re-entry.

I am using the .f90 extension, and it isn't working properly for me.
If it is not allowed in the f95 standard then I might head in the direction of trying to eliminate the common statements rather than attempting to make them work.
 
I might write a simple test program and see what that does. I'm porting over 80 or so programs, most of which are FORTRAN 77 and 90. Some use common. I'm sure I've successfully ported one that used common, yet 2 at least recently failed specifically in the common statement, not doing as I expected.  
 
Thanks for the reply.
Cheers,
Max

A simple test case of one integer variable in a common and setting it in both the main and subroutine, behaved as expected.
The failing code mentioned above had a dozen or so variables, possibly differing types, and rather large multimensional and single dimensional arrays of varying sizes, and not in order of largest to smallest as I've seen mentioned as advisable, in my searches.

Is it possible that there is a typo in the variable names.  Try IMPLICIT NONE (A-Z) before the common block and see what comes out.

Some code from the program I had to port ('implicit none' NOT used). The main problem was the mrain, krain arrays were updated in one or both subroutines but when referenced in main later the values were different to what was set. Variables were not likely typo'd as they were working in a previous life.

PROGRAM AAA

COMMON NAME(20),B(12,12),IX(750),IPER(10),LX(10),A(201),AX(24),LRAIN(201,12),JRAIN(1000),KRAIN(1000),MRAIN(201,10),LC(10),LR(10)
 
END PROGRAM AAA

 
SUBROUTINE BBB(LA,LB,K,NB,LIM,NOPAR)

COMMON NAME(20),B(12,12),IX(750),IPER(10),LX(10),A(201),AX(24),LRAIN(201,12),JRAIN(1000),KRAIN(1000),MRAIN(201,10),LC(10),LR(10)
 
variables used inside subroutine BBB: II, NOPAR, LA, LC(K), K, LR, I, MRAIN, LB, NB, LIM, KRAIN, J
 
 
LR, LC, MRAIN, KRAIN passed via common and used in subroutine(the rest not actually used in the subroutine)
 
 
SUBROUTINE CCC(LR,JCAL,ICAL,NOCUT)

COMMON NAME(20),B(12,12),IX(750),IPER(10),LX(10),A(201),AX(24),LRAIN(201,12),JRAIN(1000),KRAIN(1000),MRAIN(201,10),LC(10),LR(10)
 

 
LR(I), LC( ), MRAIN( ), IX passed via common (the rest not actually used in the subroutine)
 
 
p.s. Testing a small program does indeed show common works as I expect, but as you can see the above code is a more complex example, and which works on our HP system, but not in Linux gfortran44.

I tested the attached code,derived from your example, with gfortran 4.4.4, even linking main program and subroutines from different source files, and the printed values look as expected, so it seems that the tested variables are really in common (the only thing I modified is the LR argument in CCC which has been renamed because it coincides with a variable in the common block).

So it seems I cannot reproduce your bug, can you comment on this? Maybe you were meaning a different problem?

PROGRAM AAA
COMMON NAME(20),B(12,12),IX(750),IPER(10),LX(10),A(201),AX(24),LRAIN(201,12),JRAIN(1000),KRAIN(1000),MRAIN(201,10),LC(10),LR(10)

LR(:) = -7
LC(:) = -9
MRAIN(:,:) = -11
KRAIN(:) = -13
IX(:) = -15
LX(:) = -17

CALL bbb()
CALL ccc()

END PROGRAM AAA


SUBROUTINE BBB(LA,LB,K,NB,LIM,NOPAR)
COMMON NAME(20),B(12,12),IX(750),IPER(10),LX(10),A(201),AX(24),LRAIN(201,12),JRAIN(1000),KRAIN(1000),MRAIN(201,10),LC(10),LR(10)

PRINT*,'BBB'
PRINT*,MAXVAL(lr),MINVAL(lr)
PRINT*,MAXVAL(lc),MINVAL(lc)
PRINT*,MAXVAL(mrain),MINVAL(mrain)
PRINT*,MAXVAL(krain),MINVAL(krain)
PRINT*,MAXVAL(ix),MINVAL(ix)
PRINT*,MAXVAL(lx),MINVAL(lx)

END SUBROUTINE BBB


!SUBROUTINE CCC(LR,JCAL,ICAL,NOCUT)
SUBROUTINE CCC(LS,JCAL,ICAL,NOCUT)

COMMON NAME(20),B(12,12),IX(750),IPER(10),LX(10),A(201),AX(24),LRAIN(201,12),JRAIN(1000),KRAIN(1000),MRAIN(201,10),LC(10),LR(10)

PRINT*,'CCC'
PRINT*,MAXVAL(lr),MINVAL(lr)
PRINT*,MAXVAL(lc),MINVAL(lc)
PRINT*,MAXVAL(mrain),MINVAL(mrain)
PRINT*,MAXVAL(krain),MINVAL(krain)
PRINT*,MAXVAL(ix),MINVAL(ix)
PRINT*,MAXVAL(lx),MINVAL(lx)

END SUBROUTINE CCC

Select allOpen in new window

Thankyou all for your replies.
Thankyou for the testing dcesari.
I built up a test example and gradually made it more and more complex and on every occasion it behaved as expected, so in a test program I could not demonstrate the problem.
The program that was failing however showed there was a problem, as I did the same thing as you did dcesari by doing prints before during and after calls to subroutines which modified the common variables and the results were unexpected/wrong and caused different answers to similar code on the HP. By changing the variables to arguments in the subroutines and removing them from common the results were the same across the HP and Linux systems.
As I have a truckload of programs to port across in limited timeframe I don't think I will spend any more time on it, unless it starts biting my backside again later in this program porting exercise. I'll simply take common out of the equation to fix any problems that arise.
 
No idea who I should allocate points to, or just share it around for efforts involved. I shall ponder! (If I do revisit the offending code and discover anything I shall endeavor to post here.)
 
Many thanks.
Max

p.s. I mistakenly added the LR in the 2nd subroutine, as I was beginning to test out passing the variable as an argument rather than via common at that stage and forgot to clean it out when posting, well picked up dcesari.

Whilst I could not replicate the problem in a small section of code I found the answers to assist greatly.

Many thanks,
Max