Block Data and 64-bit

Is there an issue with BLOCK DATA for 64-bit?

I have many common blocks that are initialized in BLOCK DATA routines (separately compiled), yet the contents of variables in these blocks show always as zeroed (/RELEASE).

If the BLOCK DATA routines require some additional syntax somewhere to get loaded, that would be much appreciated.

If this is so outmoded (and I admit it might be), what would you suggest for initialization of COMMON blocks?

Bill

Please provide example code and instructions to produce and observe described behaviour.

The following code works as expected. Compile with /debug, link and open in the debugger.

! examine BLOCK DATA
BLOCK DATA xyz
   implicit none
   real x, y, z
   common /uvw/x, y, z
   data x,y,z/1.0,2.0,3.0/
END BLOCK DATA xyz

program mypgm
   implicit none
   real x, y, z
   common /uvw/x, y, z
   
   print *,x,y,z
end program

Section B3 of of the Fortran 2018 standard lists 'Obsolescent Features'. Section B.3.11 says:

B.3.11 COMMON and EQUIVALENCE statements and the block data program unit 1 Common blocks are error-prone and have largely been superseded by modules. EQUIVALENCE similarly is error-prone. Whilst use of these statements was invaluable prior to Fortran 90 they are now redundant and can inhibit performance. The block data program unit exists only to serve common blocks and hence is also redundant.

In my own experience, I have seen that COMMON blocks in medium size and large programs cause a lot of trouble. They may be replaced by using module variables, user-defined composite types, etc.

I think there is a problem with BLOCK DATA I recall that early versions of FTN95 /64 Ver 8 did not support BLOCK DATA, although I can't find the reference. I think MODULE does allow initialisation but with limits.

noteson64bitftn95.txt states:

Arrays that are ALLOCATEd, or which are in COMMON or in MODULEs can exceed the 4GB limit, except that initialised arrays must fit within the .EXE or .DLL file to which they belong, and the the size of these files cannot extend beyond the 4GB limit. This is a Microsoft limit, but is fairly reasonable, since the time needed to load a 4GB file would be excessive!

John,

I had a vague notion that BLOCK DATA and BLOCK COMMON had an issue. I seemed to remember postings from long ago, and went looking, but the search parameters picked up a lot of extraneous stuff, and not all 64-bit problems are in that branch of the forum.

I think it is the way the object modules are linked. My reasoning: if I could force the BLOCK DATA objects to load into the executable, then all will work. That's the way the 32-bit compiler and linker works. It makes EXTERNAL the name of the common block and the BLOCK DATA provides a named ENTRY point. Apparently something like that doesn't happen with 64-bit.

My solution was to make each BLOCK DATA into a named subroutine. I included a STOP statement just so it was guaranteed to have code generated. Then, in one of the routines common to ALL my executables, I included a CALL to those now named subroutines that would never actually be executed, but this forces the initialization data to be loaded.

Now, I'm past (I think) problems with uninitialized data, and on to those 'C' interfaces that are not working in 64-bit.

Bill

I don't know of any current problems with BLOCK DATA so please let me know if any are discovered.

Hi, Paul!

I think the issue I was having was that BLOCK DATA was not getting loaded and used either during the link, or at run-time. And I was unaware of how to force it so.

Background: I discovered this early on once I had a good, complete executable made. One of the first things was to use a character variable in NAMED COMMON. It failed, and the error was reported by CLEARWIN. I placed some debug at the point of the error and discovered that the variable, supposed to be initialized via BLOCK DATA, was all zeroes. There were other indicators that things were not going well, like the default output unit S/B 1 and was 0. There are still a few things that are not working in 64-bit as I would have expected, but I suppose I should have anticipated that.

By using the technique I gave earlier in this post, I was able to get the named COMMON initialized properly, and recognized at run-time as being initialized.

I don't know if this is a 'problem with BLOCK DATA' or if I should have used some other technique/process to guarantee that the BLOCK DATA subroutine would be linked and initialized at run-time.

mecej4,

All the BLOCK DATA were compiled as separate routines, not as part of a single compilation as your example intimated. It is very possible that this newer way is precisely how they should have been compiled in order for the initialization values to be applied. It is a guess on my part, and I believe that I have 'fixed' this.

Right now, with my 'fix' in place, I believe named COMMON is being initialized. That being said, I am getting odd behavior from the initialization portion of my program that could be related to COMMON initialization. It is unclear and currently under investigation.

Bill

Bill, there is a way to make sure that needed initializations in one or more BLOCK DATA program are not skipped by the linker -- something that I learned from Eddie a few years ago.

In each BLOCK DATA subprogram, add a name to the subprogram, i.e., declare

BLOCK DATA xyz

instead of just

BLOCK DATA

In each subprogram where the corresponding COMMON blocks that are included in these BLOCK DATA subprograms are used, add EXTERNAL declarations:

EXTERNAL xyz

Compile and link again. If any errors are reported by the linker, fix up your build commands/IDE project settings, etc.

mecej4,

Yes, I did that with specific names for each BLOCK DATA.

Didn't help for 64-bit.

Bill