|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2813 Location: South Pole, Antarctica
|
Posted: Sun Nov 22, 2015 4:55 am Post subject: 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 :
Code: |
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 |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Sun Nov 22, 2015 11:07 am Post subject: |
|
|
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 |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1885
|
Posted: Sun Nov 22, 2015 12:57 pm Post subject: |
|
|
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.
Code: |
!-------------
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':
Code: |
integer ccc
common /bbb/ccc
|
|
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Mon Nov 23, 2015 12:04 am Post subject: |
|
|
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 |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2813 Location: South Pole, Antarctica
|
Posted: Mon Nov 23, 2015 4:10 am Post subject: |
|
|
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?
Last edited by DanRRight on Mon Nov 23, 2015 4:19 am; edited 5 times in total |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Mon Nov 23, 2015 4:15 am Post subject: |
|
|
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 !!
Code: | 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 ? |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2813 Location: South Pole, Antarctica
|
Posted: Mon Nov 23, 2015 5:32 am Post subject: |
|
|
I may try, just tell how specifically? |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Mon Nov 23, 2015 6:04 am Post subject: |
|
|
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)
Code: | !---------------
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 |
|
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7916 Location: Salford, UK
|
Posted: Mon Nov 23, 2015 8:51 am Post subject: |
|
|
Please let me know at the end of this discussion if there is anything that needs fixing. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2813 Location: South Pole, Antarctica
|
Posted: Tue Nov 24, 2015 2:16 am Post subject: |
|
|
John,
As just a comment, for the sake of manageability of the code i am strictly opposing the use of common blocks like this
Code: |
common /bbb/var1
common /bbb/var2
|
which is equivalent to
Code: |
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.
Last edited by DanRRight on Tue Nov 24, 2015 10:47 pm; edited 2 times in total |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7916 Location: Salford, UK
|
Posted: Tue Nov 24, 2015 8:10 am Post subject: |
|
|
OK. I have logged this as needing investigation. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Tue Nov 24, 2015 6:01 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7916 Location: Salford, UK
|
Posted: Tue Jun 07, 2016 12:33 pm Post subject: |
|
|
In the next release of FTN95, this duplication will produce a compile time error as Dan has requested. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2813 Location: South Pole, Antarctica
|
Posted: Tue Jun 07, 2016 7:10 pm Post subject: |
|
|
That will definitely make compiler stronger! Thanks, Paul |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|