No warning on redundant common block

If i'd live 100+ years i'd probably know all the tricks of the devil. He is not that original, repeating and repeating himself. How many Saturdays i lost completely searching for some particularly stupid and difficult big? Such cases were documented even on this forum 😃 This was another one.

The code was supercrazy by doing totally absurd things until before pulling my last hair i discovered that i used common block in module and subroutine and in the subroutine also used the same module. Compiler did not complain but probably should.

I tried to reproduce this in small code but small code does not produce me crazy results. And of course does not complain :

module aaa
common /bbb/ccc
end module

!-------------
Program ddd
use aaa
ccc = 21
print*, ccc
call SSS
end

!---------------
subroutine SSS
use aaa
common /bbb/ccc
print*, ccc
end

Well, devil escaped but if Silverfrost fix the redundant common blocks he will have less chances

Would have picked it up if it was an include file.

If you mix styles then you venture into territory that has not been well explored. Perhaps not a devil but a sea monster ... the Kraken maybe. Tennyson's poem could have been written about compilers!

Eddie

Even with COMMON block declarations placed in included files, the peculiar properties of COMMON blocks can cause some mystifying errors to occur. The relevant rule is: 'The common block list following each successive appearance of the same common block name in a scoping unit is treated as a continuation of the list for that common block name'. The following example illustrates this.

!------------- 
Program ddd 
implicit none
include 'ddd.h'
ccc = 21 
print*, ccc 
call SSS 
print*, ccc
end 

!--------------- 
subroutine SSS 
implicit none
include 'ddd.h'
integer ccb
common /bbb/ccb 
print*, ccb
ccb=5
print*, ccb
end

The contents of the include file 'ddd.h':

integer ccc
common /bbb/ccc

I am surprised that you can use common in a module. If it is legal Fortran95, then it provides some interesting capabilities for sequencing variables that are in modules, as I thought that EQUIVALENCE and COMMON were excluded from modules.

John

Yes, John, it works perfectly and in general is very convenient good old method.

I was scared initially of this as Eddie is saying not well explored gray area but after use for couple years i find here no problems besides the one just described this thread: compiler does not complain about presence of two common blocks in the same program/subroutine if one is in module. If Silverfrost fix that all will continue work like charm.

Unlike users of all other compilers I like COMMON blocks, thanks to strict error checking of this compiler. My scare came from hysteria on comp.lang.fortran many years ago from as i now understand the users of their dumb shi@#$y fortran compilers which did not check anything

The only other problem with them i reported and asked to fix: if you have many subroutines in single file and two same name common blocks are not the same compiler complains about that but does not say the exact names of subroutines where this occured. And when this will be fixed the common blocks will never die as obsolete.

So mecej4 - is this a strict no-no of programming?

Dan,

I tested the code you have then modified to see if there was any crazy addressing, but none showed up : no duplicate addresses. I am not sure what common in a module means. I will look in the .map file, but it may be this example is too small. When does it go crazy ? I have seen in load maps that components of a module can be given their own addresses, such as allocatable arrays and presumably labelled common. Have you tried unlabelled common ? that could be crazy !!

 module aaa 
 common /bbb/ccc 
 common eee
 integer eee, ccc, fff
 end module 

 !------------- 
 Program ddd 
 use aaa 
 ccc = 21
 eee = 22
 fff = 23

 print*, 'ddd ',ccc, eee, loc(ccc), loc(eee), ' use only', loc(fff)
 call SSS 
 call YYY
 call ZZZ
 end 

 !--------------- 
 subroutine SSS 
 use aaa 
 common /bbb/ccc 
 print*, 'sss ',ccc , eee, loc(ccc), loc(eee), ' both    ', loc(fff)
 end

 !--------------- 
 subroutine YYY 
 common /bbb/ccc 
 common eee
 integer eee, ccc
 print*, 'yyy ',ccc , eee, loc(ccc), loc(eee), ' common only'
 end

 !--------------- 
 subroutine ZZZ
 use aaa 
 print*, 'zzz ',ccc , eee, loc(ccc), loc(eee), ' use only', loc(fff)
 end 

Running this code shows the module address is away from the common addresses so no problem there. what about mixing local and module variables of the same name ?

I may try, just tell how specifically?

Dan,

I tried and could not have the same name for a local variable and one in a module. not sure how that happened. However, I could repeat a common declaration, which basically extends the length of the common (this should give a warning in slink)

 !--------------- 
 subroutine SSS 
 use aaa 
 common /bbb/ccc 
 integer fff            !  this gives an error
 print*, 'sss ',ccc , eee, loc(ccc), loc(eee), ' both    ', loc(fff)
 end

 !--------------- 
 subroutine YYY 
 common /bbb/ccc 
 common /bbb/fff        ! this is ok, it extends the length of common bbb
 common eee
 integer eee, ccc, fff  ! fff is local
 print*, 'yyy ',ccc , eee, loc(ccc), loc(eee), ' common only', loc(fff)
 end

Please let me know at the end of this discussion if there is anything that needs fixing.

John, As just a comment, for the sake of manageability of the code i am strictly opposing the use of common blocks like this

common /bbb/var1
common /bbb/var2

which is equivalent to

common /bbb/var1, var2

That must be forbidden in Fortran, or slowly derailed as obsolete. As well as partial list of variables in common blocks used in different subroutines. The list of variables in the common blocks must be absolutely identical in number and type of variables, period. I do not know what sick brain allowed it in the first place. Even though they are valid Fortran, please experiment without these options.

The most sensitive to the subject of this thread is Clearwin+. Just to doublecheck I added the redundant common block into subroutine again and my large code (not this example above) immediately started making crazy things with Clearwin radiobuttons %rb and %ga making all radiobuttons dancing ON or all OFF at the same time. And again, i could not reproduce this bug in small code. I can post the entire code for anyone to play, this one is not large, just two files 15K lines total

Paul, Definitely FTN95 must not allow duplication of identical common blocks in the same subroutine (one directly and one via module) like it is doing with two common blocks in the same code right now. It could be of course hard to distinguish duplication from addition of second common block to the first one like John used. How and what compiler assigns with this duplication which is equivalent to

COMMON /bbb/ var1, var1

is not for my exhausted brain 😃. Multiple declarations of same common blocks to add variables to list is very bad practice to write the code because it makes holly mess: programmer now does not know himself what the common block actually consists of. This mess in Standard probably caused negativity to the common blocks in Fortran-90 and its development went different path via modules etc.

OK. I have logged this as needing investigation.

I knew that Mecej4 would know the answer as to why it works, which is a feature of Fortran that like some others is plain stupid.

Why it shouldn’t work is that the variables are named with the same names. So, if in the Module there was COMMON /A/ B, C and in the routine there was COMMON /A/ D, E, it would be the same as COMMON /A/ B, C, D, E

However, having the same variable names in both is like having COMMON /A/ B, C, B, C, and Fortran Standard or not that ought to generate an error.

Perhaps the repeated use of a COMMON block name ought to generate a warning, if it is permissible under the standard.

In the next release of FTN95, this duplication will produce a compile time error as Dan has requested.

That will definitely make compiler stronger! Thanks, Paul