length of shared named COMMON

[jwasson]

IVF documentation says:

The COMMON statement "defines one or more contiguous areas, or blocks, of physical storage. When common blocks from different program units have the same name, they share the same storage area when the units are combined into an executable program. Named common blocks must be declared to have the same size in each program unit. Blank common can have different lengths in different program units."

Does IVF reliably 'extend' the memory of a named common to the largest allocation? Or is the constraint "Named common blocks must be declared to have the same size in each program unit" enforced in some ways.

It appears that a even named common block can have contiguous memory from the largest allocation. For example

subroutine use_common

real some_bytes

common /memory/some_bytes

EXTERNAL bd

call sub1(some_bytes)

return

end

subroutine sub1(lots_of_bytes)

real lots_of_bytes(*)

! use lots of bytes up to allocation in bd

! at your own risk (access in excess of

! allocation in bd, mis-alignment of

! 'heterogeneous' items ...)

return

end

blockdata bd

integer lots

parameter ( lots = 123 )

real work(lots)

common /memory/work

end

EXTERNAL bd seems to allow the allocation in the blockdata.

[Steven_L_Intel1]

The only thing we support is blank common with different lengths. If you have a named common with different lengths, the results are unpredictable as the linker will choose whichever definition it finds first.

[jwasson]

(this might inadvertently be a duplicate reply because of the internet connection)

Should the linker predictablyencounter block data first since block data " provides initial values

for nonpointer variables in named common blocks?" Then EXTERNAL bd would provide the

allocation from block data (whether it was the greatest or not).

[Steven_L_Intel1]

My experience is that it is unpredictable. Don't try to depend on it being otherwise.

[TimP]

When running with the Intel OpenMP library, an attempted increase in the size of a threadprivate common block at run time is detected and the run is aborted.

[jwasson]

Just for completeness, if a COMMON is statically allocated and exported

subroutine alloc

integer size

parameter (size = 123)

real somebytes(size)

!dec$ attributes dllexport :: /cex/

common /cex/ somebytes

integer cexsize

data cexsize/size/

!dec$ attributes dllexport :: /csizes/

common /csizes/ cexsize

and then imported in some dll

subroutine usesomebytes

real somebytes(1)

!dec$ attributes dllimport :: /cex/

common /cex/ somebytes

integer cexsize

!dec$ attributes dllimport :: /csizes/

common /csizes/ cexsize

...

the imported COMMON will have the exported size (but there is still a risk of misalignment with 'heterogeneous' items, seqential requirements, ..., risk of accessing outside the size unless you check ..., ...)

[mecej4]

>Should the linker predictablyencounter block data first since block data provides initial values

Not a good assumption.

An anecdote to cast light on this question: I had a large program, in which there were many large named COMMON blocks and, in a separate source file by itself, one BLOCK DATA subprogram in which all the needed initializations were done.

By mistake, the .obj file for the BLOCK DATA was not named in the makefile rule for linking the program. No complaints from the linker, junk results when the program was run.