How to Force Common Block Ordering?

[danhoyt]

Help! I have 80K LOC of legacy Fortran that works perfectly under CVF, but not under IVF (any version -- I've tried 8.0, 8.1, 9.0, 9.1, and 10.0.017). I keep running across problem after problem -- here's the latest:

I have a module with statements that don't appear to do anything (i.e. "VAR1=VAR1"), but they're crucial for ensuring specific ordering of about 160 common blocks. For each of those common blocks, there's a do-nothing reference as above to the first variable in the common block.Under CVF, this referencing ordered the common blocks in the order specified by the references. However, under IVF, these statements don't even produce any code! Here's an example:

---------- IVFBadCommons.for: ----------
PROGRAM IVFBadCommonsIMPLICIT REAL*8 (A-H,O-Z)INCLUDE 'Common1.f'INCLUDE 'Common3.f'INCLUDE 'Common2.f'WRITE(*,*) 'Setting up common variables that are never referenced'CA1VAR1=CA1VAR1CC3VAR1=CC3VAR1CB2VAR1=CB2VAR1WRITE(*,*) 'Done setting up common variables'END
---------- Common1.f: ----------
COMMON/ACOMMON1/1 CA1VAR1 , CA1VAR2 , CA1VAR3COMMON/BCOMMON1/1 CB1VAR1 , CB1VAR2 , CB1VAR3
---------- Common2.f: ----------
COMMON/BCOMMON2/1 CB2VAR1 , CB2VAR2 , CB2VAR3COMMON/ACOMMON2/1 CA2VAR1 , CA2VAR2 , CA2VAR3
---------- Common3.f: ----------
COMMON/CCOMMON3/1 CC3VAR1 , CC3VAR2 , CC3VAR3

I understand that IVF issmarter about compiling code,and I realize the long-term solution is to fix the code so it doesn't require specific common block ordering, but I still need a solution now or we'll simply have to abandon IVF until the code is fixed (which could take 1-2 years, depending on our funding).

Does anyone know of a compiler switch or code technique I can employ to arbitrarily specify the common block ordering?

-Dan Hoyt, Senior Systems Architect, Technology Service Corporation, Colorado Operations

[Steven_L_Intel1]

I don't think the assignments changed the order in CVF. Like in IVF, they establish references, but the optimizer in IVF can see that the values are never used so they are thrown away.

The common block ordering would likely be by the order in which they were seen. I can't imagine the assignments having any connection with this other than that references were created.

Try the following:

Add VOLATILE statements for the COMMONs:, for example:

VOLATILE :: /ACOMMON1/
VOLATILE :: /BCOMMON1/
etc.

You should add these in the include files for the respective commons. I tried this and got the order:

0003:0000d7a0 _ACOMMON1 0047f7a0
0003:0000d7c0 _CCOMMON3 0047f7c0
0003:0000d7e0 _BCOMMON2 0047f7e0

The other commons are not referenced at all so do not get allocated. If you had references in other routines that would likely not happen.

[danhoyt]

Steve,

Thanks for your prompt reply. I'm not sure what you mean by "the common block ordering would likely be the order in which they were seen." If it's not the include order or the assignments, when are they "seen" for ordering? My current map looks like:

0003:000066a0 _ACOMMON2 0046f6a0 
0003:000066c0 _BCOMMON2 0046f6c0 
0003:000066e0 _CCOMMON3 0046f6e0 
0003:00006700 _BCOMMON1 0046f700 
0003:00006720 _ACOMMON1 0046f720 

which is neither the include order nor the assignment order.

If I understand your VOLATILE suggestion, in order for it to work properly, I'll need to add references to ALL common blocks used:

CA1VAR1=CA1VAR1CB1VAR1=CB1VAR1CC3VAR1=CC3VAR1CB2VAR1=CB2VAR1CA2VAR1=CA2VAR1

in order to ensure all my common blocks are loaded.

You may be right about CVF's non-use of the assignments--this code is cross-platform for Win32 and several *nixes; I know that the assignments wererequired for correct ordering in SGI, but I don't know that for sure about CVF. In the project, there's another module that contains each common block inside a BLOCK DATA statement -- perhaps that what CVF uses for the ordering? I didn't include that complication in this simple test case, but I'll go back and look at that if needed after I try your VOLATILEsuggestion in my project.

-Dan Hoyt

[Steven_L_Intel1]

By "seen" I meant lexical order of the common block declarations in the program, but this assumes that the compiler emits in the object code the common blocks in that order. I don't think there's a particular guarantee of that.

I know that on VMS, an OS I once worked on, you were guaranteed that COMMON blocks would be loaded in alphabetical order. They were seen as distinct "program sections" by the linker and there was a linker rule that program sections were sorted alphabetically. There were even VMS features that depended on that behavior.

On Windows and Linux, there is no such guarantee or correspondence. Uninitialized COMMON blocks go in a "bss" image section which takes up no space in the executable - space is allocated when the EXE is run. Initialized COMMON blocks go in the .data section, but again all lumped together. Intel Fortran does not offer a way to separate out a COMMON into its own image section.

You may want to rethink this approach - perhaps consider a single COMMON that has all of the necessary pieces in the right order. Or maybe there's some other approach. Sadly, many of the old Fortran "tricks" of the past stop working as compilers get smarter.

[jimdempseyatthecove]

If the VOLATILE doesn't work

Try changing

CA1VAR1=CA1VAR1
CC3VAR1=CC3VAR1
CB2VAR1=CB2VAR1

To

CA1VAR1=DoNothing(CA1VAR1)
CC3VAR1=DoNothing(CC3VAR1)
CB2VAR1=DoNothing(CB2VAR1)

Where DoNothing is a dummy function that returns the value entered.

Make sure it is in an external compilation unit or project, or options set such that it is not optimized out.

Jim Dempsey

[danhoyt]

Steve, I get a compile error with "VOLATILE ::" syntax, because the COMMON block hasn't been defined. Instead, I added "VOLATILE /ACOMMON1/,/BCOMMON1/" and similar statement at the end of each .F file, but the .MAP showed the allocation exactly backward.

Jim, I triedanexternalDoNothing() function, but the .MAP also showed the allocation exactly backward.

Based on Steve's explanation, I reasoned that the BLOCK DATA moduleI omitted from the test case are actually what's ordering my common blocks in CVF. Sure enough, the common blocks are ordered properly if Icomment outthe statements that don't generate code in IVF and initialize the variables in BLOCK DATA:

PROGRAM IVFBadCommonsIMPLICIT REAL*8 (A-H,O-Z)
C INCLUDE 'Common1.f'
C INCLUDE 'Common3.f'
C INCLUDE 'Common2.f'WRITE(*,*) 'Setting up common variables that are never referenced'
C CA1VAR1=CA1VAR1
C CB1VAR1=CB1VAR1
C CC3VAR1=CC3VAR1
C CB2VAR1=CB2VAR1
C CA2VAR1=CA2VAR1WRITE(*,*) 'Done setting up common variables'ENDBLOCK DATA BLK1IMPLICIT REAL*8 (A-H,O-Z)INCLUDE 'Common1.f'DATA CA1VAR1 /111.0/ , CA1VAR2 /112.0/ , CA1VAR3 /113.0/DATA CB1VAR1 /211.0/ , CB1VAR2 /212.0/ , CB1VAR3 /213.0/END
BLOCK DATA BLK3
IMPLICIT REAL*8 (A-H,O-Z)INCLUDE 'Common3.f'DATA CC3VAR1 /331.0/ , CC3VAR2 /332.0/ , CC3VAR3 /333.0/ENDBLOCK DATA BLK2IMPLICIT REAL*8 (A-H,O-Z)INCLUDE 'Common2.f'DATA CB2VAR1 /221.0/ , CB2VAR2 /222.0/ , CB2VAR3 /223.0/DATA CA2VAR1 /121.0/ , CA2VAR2 /122.0/ , CA2VAR3 /123.0/END

However, since my project already does this, I realized I'm chasing the wrong problem. The lack of code generation isn't the issue at all, but something else in my project code. My legacy code gave me an error that seemed to indicate the common blocks were out of the expected order, and I wrote the test case under that assumption, which turned out to be false. After Steve's explanation, I realized I'd never checked the .MAP files against the expected ordering. I did and found them to be correct.

Bottom line, initializing the common block variables in BLOCK DATA neatly forces the common block ordering in CVF (but not all *nixes, BTW), and I've got a different problem to solve.

[Steven_L_Intel1]

I'm not sure what you did regarding VOLATILE as I added VOLATILE declarations at the end of each include file and it worked. Good luck in finding the "real problem".