forums.silverfrost.com

[JohnCampbell]

Paul,

I am again getting a warning message about inconsistent common block lengths, when using FTN95 ver 5.30 and SLINK ver 1.42. A typical warning is:-

WARNING - Common block "JUNK/" was previously defined in object file C:\ceasap_review\ceasap_2009\elinpt.obj as size 432 but is now defined as size 688 (C:\ceasap_review\ceasap_2009\beam.obj)

I had previously overcome this warning, by
declaring an equivalent variable that was the maximum length used for this common and also declaring the common block in the main program.

A typical declaration looks like:-
COMMON /JUNK / TELOAD(9,6)
REAL*8 DUMJNK(750), TELOAD
EQUIVALENCE ( DUMJNK, TELOAD )

The variable DUMJNK implies the common block is 6,000 bytes long.
The number of variables in the common /JUNK/ varies quite a lot; a hang over from small memory days where JUNK was a pool of shared memory for many parts of the program.

It now appears that :-
1) the equivalence is not being used to define the common block length, and also
2) the initial declaration in the main program module is not being used in SLINK.

This appears to be happening as:-
1) variable DUMJNK is not referenced elsewhere in each subroutine and
2) in the main program, the variables in the common block are not otherwise referenced.

Is this a cosmetic regression or more serious ?

Implied in the fortran standard is that common blocks are not considered static, and can be undefined if the program goes outside the extent of where the common is defined. Hence there was the need to define all common in the program module. Is this assumption being threatened by the common appearing to not be defined in the program module ?

It does not appear to be happening to the length of other COMMON declarations where trailing variables declared in common blocks are not referenced in the subroutine, only the variable that is used via EQUIVALENCE, to fudge the defined length of the common.

John

[PaulLaidler]

John

I don't think that SLINK has changed.
Are the blocks actually the same size?
Do you get the warning after you have recompiled everything with the new version of FTN95?

Regards

Paul

[JohnCampbell]

The warnings have re-appeared after many years after now using ver 5.30.

Many years ago (Pr1me and Apollo days), all common block definitions were different lengths, so I included a variable DUMJNK(750), which I equivalenced to the start of each definition, to make the compiler define each /JUNK/ occurrence as the maximum size.

Now, with Ver 5.30, the compiler now appears to be ignoring the DUMJNK equivalence, presumably as the variable DUMJNK is not actively used elsewhere in each subroutine.

The other worrying point, is that /JUNK/ is defined (listed) in the main program module, as the full length of 6,000 bytes, although again, no variables in this common block are referenced in the main program module. Based on the error message of lengths, it appears the definition in the program routine, which is the first .obj to be linked, does not define the length of /JUNK/, but uses a later definition, which apparently ignored the equivalence to extend the implied length and indicates a length of only 432 bytes.

My use of EQUIVALENCE to remove the common length warning may go back to FTN77 or when I first started using FTN95, so this occurrence at Ver 5.30 is a recent change.

John

[JohnCampbell]

Paul,

I have mislead you on the nature of the common warning.

It appears that the use of EQUIVALENCE to fudge the length of common has not worked for a long time. It may go back to 2000, or possibly all of FTN95. This must have been a change I implemented when I started using Salford FTN77 or some other pre ftn95 compiler !

However, with FTN95 v5.30, the common declared in the main PROGRAM module, but not referenced with an executable statement, is either not being implemented by SLINK, or not being included in the .obj file. I have overcome this particular occurrence by placing an initialisation line in the main program, but this is a change at v5.30.

It appears that any common that is only declared in the main Program, but not otherwise referenced, is being ignored. This did not happen prior to ver 5.30.

As I asked before, this has implications for the warning in the fortran standard about the dynamic nature of common. Given that common appears to be static in ftn95/slink, this may not be a significant issue.

John

[JohnCampbell]

Paul,

Further to my last correction, I now can NOT reproduce the error message that appears in my first post. The compiler / linker is now behaving as with Ver 5.21.

For my last post, I changes the program, to include an executable statement " DUMJNK = 0", but did not retest the problem !
The only thing I can think of is that I did not shut down and restart my computer, after installing Ver 5.30, before carrying out the test that failed.
I have gone back to backup copies of the source code of 2 months ago, but there are no changes in the code for the version I tested.

Of interest, from searching through my archives, my use of EQUIVALENCE to dummy the common length, dates back to at least 1991, so I'm not sure for what compiler I installed this for and when it stoped working. This may even be before I started using FTN77/DBOS.

I'll go back and carefully test the 3gb / allocate, using /debug before I comment again.

John