Conference turris::fortran

Digital FORTRAN on NT (both Intel and Alpha) implements COMMON blocks using 
object file COMMON symbols (section -1, external storage class, COMMON block 
size in the value field).  It is the Linker, not the compiler, that determines 
the final size of the COMMON block.  On both Windows NT Intel and Windows NT 
Alpha, the Linker maximizes the size of each COMMON block--it chooses the 
largest size encountered in any object module that contributes to the image.
The test examples that I have run verify that this is the case.

OpenVMS and Digital UNIX also have Linkers that perform COMMON block size 
maximization.

I suspect that there must be some other cause for this problem in your 
application.  But if it is a failure to maximize the size of the COMMON block, 
that is the fault of the Linker and not the Digital FORTRAN compiler.  The 
compiler has no control over whether COMMON blocks are maximized.

--PSW

One other thing, that might have a bearing on your problem:

The Linker can only do maximization on COMMON block contributions that are 
uninitialized.  If any source file initializes a COMMON block, the COMMON block 
gets that size and can't be maximized.

--PSW

    	From what little information you provide, it looks like you
    might have stepped outside the larger version of the common block
    by having a value for "I" which is greater than 100.  Because of
    the way the program is written, you will NOT be able to use
    bounds checking unless you modify the common blocks to all have
    the SAME sizes.  Are you certain that the value of "I" is not
    greater than 100 when the damage occurs?
    
    Cheers!
    Dave Eklund
    

Thank your advices.
I checked the output of OBJ's DUMPBIN and MAP.
It seems the output of DUMPBIN isn't wrong.
But MAP is wrong. Linker don't allocate the maxsize of named common.

The following list is a part of MAP.

 0003:0012a918       arsize_                    00bd2918  <-- size is OK 
PROWinLib:PROGlobalMem.obj
 0003:0012a9b8       cycle_                     00bd29b8   
            B8-18 = A0 <-- This is same of ARSIZE.

 0003:0011a008       dbaseb_                    00bc2008   
PROWinLib:PROGlobalMem.obj
 0003:0011a018       dbasec_                    00bc2018   
PROWinLib:PROGlobalMem.obj
 0003:0011a028       dbasel_                    00bc2028   
PROWinLib:PROGlobalMem.obj
 0003:0011a038       dbases_                    00bc2038   
PROWinLib:PROGlobalMem.obj
 0003:0011a048       pdata_                     00bc2048   
PROWinLib:PROGlobalMem.obj
 0003:0011a060       dbasev_                    00bc2060  <-- Don't allocate maximam size. 
PROWinLib:PROGlobalMem.obj
 0003:0011a070       ctable_                    00bc2070   
                        70-60=10 <-- This isn't the max size of DBASEV.

Kouji

Ex.

  a.f ---------------------

C STORAGE FOR DATABASE ARRAYS
      PARAMETER( MAXCEL=12000 )
      PARAMETER( MAXVRT=18000 )
                    .
                    .
      COMMON/DBASEC/NLCS,NLC1,NLC2,LCELL(MAXCEL)
      COMMON/DBASEV/NLVS,NLV1,NLV2,LVERT(MAXVRT)
      COMMON/DBASEB/NLBS,NLB1,NLB2,LBOUND(MAXBND)
      COMMON/DBASBL/NLBKS,NLBK1,NLBK2,LBLK(MAXBLK)
      COMMON/DBASES/NLSS,NLS1,NLS2,LSPL(MAXSPL)
      LOGICAL*1 LCELL,LVERT,LBOUND,LBLK,LSPL
                    .
                    .
                    .

  b.f  ----------------

      SUBROUTINE INIT1
      COMMON/ARSIZE/MAXCEL,MAXVRT,MAXPST,MAXCUT,MAXDAR,MAXFAC,MAXBRK,
     1              MAXSID,MAXBND,MAXNBU,MAXB1D,MAXREG,MAXNCY,MAXRST,
     2              MAXOBS,MAXOBF,MXIJK,MAXSPL,MAXBLK,MAXTAB,MAXINF,
     3              MAXSC1,MAXSC2,MAXPRB,MAXKT,MAXNCP,MAXPS2,MAXPR2,
     4              MAXVR2,MXSTOR,MAXDRP,MAXPR,MAXBCP,MAXEVE,MAXCEV,
     5              MAXEAT,MAXEDE,MAXREF,MAXRGS,MAXASI
	:
	:
C STORAGE FOR DATABASE ARRAYS
      COMMON/DBASEC/NLCS,NLC1,NLC2,LCELL(1) <-- size is deffrent from a.f
      COMMON/DBASEV/NLVS,NLV1,NLV2,LVERT(1) <-- size is deffrent from a.f
      COMMON/DBASEB/NLBS,NLB1,NLB2,LBOUND(1) <-- size is deffrent from a.f
      COMMON/DBASBL/NLBKS,NLBK1,NLBK2,LBLK(1) <-- size is deffrent from a.f
      COMMON/DBASES/NLSS,NLS1,NLS2,LSPL(1)   <-- size is deffrent from a.f
      LOGICAL*1 LCELL,LVERT,LBOUND,LBLK,LSPL
	:
	:
      DO 10 I=1,MAXVRT
10      LVERT(I)=.FALSE	  <-- destroy ARSIZE common block	
      DO 20 I=1,MAXCEL
20      LCELL(I)=.FALSE.
	:


[  DUMPBIN of a.obj  ]
00000000 SECT1  notype ()    External     | prostar_
000000A0 UNDEF  notype       External     | arsize_   
000000D8 UNDEF  notype       External     | spdint_
00000198 UNDEF  notype       External     | spdign_
00000000 UNDEF  notype ()    External     | promain_
0020F580 UNDEF  notype       External     | nodes_
0000000C UNDEF  notype       External     | pstnd1_
0000000C UNDEF  notype       External     | pstnd2_
0041EB00 UNDEF  notype       External     | cells_
0001D4CC UNDEF  notype       External     | dbasec_
0002BF2C UNDEF  notype       External     | dbasev_  
00005DCC UNDEF  notype       External     | dbaseb_
00000070 UNDEF  notype       External     | dbasbl_
00000200 UNDEF  notype       External     | dbases_


[  DUMPBIN of b.obj  ]
00000000 UNDEF  notype ()    External     | resume_
00008FE0 UNDEF  notype       External     | props_
000000A0 UNDEF  notype       External     | arsize_
0000000D UNDEF  notype       External     | dbasec_
0000000D UNDEF  notype       External     | dbasev_
0000000D UNDEF  notype       External     | dbases_
0000000D UNDEF  notype       External     | dbasbl_
0000000D UNDEF  notype       External     | dbaseb_

[  Output of MAP  ]

 0003:0011a008       dbaseb_                    00bc2008   
PROWinLib:PROGlobalMem.obj
 0003:0011a018       dbasec_                    00bc2018   
PROWinLib:PROGlobalMem.obj
 0003:0011a028       dbasel_                    00bc2028   
PROWinLib:PROGlobalMem.obj
 0003:0011a038       dbases_                    00bc2038   
PROWinLib:PROGlobalMem.obj
 0003:0011a048       pdata_                     00bc2048   
PROWinLib:PROGlobalMem.obj
 0003:0011a060       dbasev_                    00bc2060  <-- Don't allocate maximam size. 
PROWinLib:PROGlobalMem.obj
 0003:0011a070       ctable_                    00bc2070   
PROWinLib:PROGlobalMem.obj
 0003:0011a098       constc_                    00bc2098   
PROWinLib:PROGlobalMem.obj
 0003:0011a0b0       loginf_                    00bc20b0   
PROWinLib:PROGlobalMem.obj
 0003:0011a0d8       cntrl_                     00bc20d8   
PROWinLib:PROGlobalMem.obj
 0003:0011a388       newkey_                    00bc2388   
PROWinLib:PROGlobalMem.obj
 0003:0011a798       trdata_                    00bc2798   
PROWinLib:PROGlobalMem.obj
 0003:0011afa0       scrt3_                     00bc2fa0   
PROWinLib:PROGlobalMem.obj
 0003:0011e330       lsave_                     00bc6330   
PROWinLib:PROGlobalMem.obj
 0003:0011e3e0       envvar_                    00bc63e0   
PROWinLib:PROGlobalMem.obj
 0003:0011e548       motifq_                    00bc6548   
PROWinLib:PROGlobalMem.obj
 0003:0011f5c8       motifs_                    00bc75c8   
PROWinLib:PROGlobalMem.obj
 0003:0011f618       poros_                     00bc7618   
PROWinLib:PROGlobalMem.obj
 0003:00120d50       postd_                     00bc8d50   
PROWinLib:PROGlobalMem.obj
 0003:00128d48       couple_                    00bd0d48   
PROWinLib:PROGlobalMem.obj
 0003:00128e18       twolay_                    00bd0e18   
PROWinLib:PROGlobalMem.obj
 0003:00129150       pltkey_                    00bd1150   
PROWinLib:PROGlobalMem.obj
 0003:001291d8       spline_                    00bd11d8   
PROWinLib:PROGlobalMem.obj
 0003:00129370       locdef_                    00bd1370   
PROWinLib:PROGlobalMem.obj
 0003:0012a918       arsize_                    00bd2918  <-- size is OK 
PROWinLib:PROGlobalMem.obj
 0003:0012a9b8       cycle_                     00bd29b8   
PROWinLib:PROGlobalMem.obj
 0003:0012aa88       regdef_                    00bd2a88   
PROWinLib:PROGlobalMem.obj
 0003:0012ab68       lites_                     00bd2b68   
PROWinLib:PROGlobalMem.obj

    	Are any elements of the common block dbasev data initialized?
    If so, as Paul points out, you MUST declare the initialized
    version as large as necessary (preferably you should declare
    all copies the same size, of course).
    
    Cheers!
    Dave Eklund
    

	It looks most likely that the issue is that there are some common 
 blocks that are being initialized in various subroutines/functions or
 a block data.  Most systems/environments pad out the commons to the largest
 instance and if we were not doing this, I suspect we would have lots of
 people noticing (and complaining).  

	While it may be a lot of work to find al definitions of the commons and
 make them the same size, it will be far less work to find commons that 
 that are getting initialized.  Perhaps you could

	collect all of the initilizations into a single block data module

	at least define the common blocks in those modules that are doing any
	initilizations as being 'large'.  Here 'large' means arbitrarily
	large (or at least as large as any other reference).

	Mike



p.s. It still does seem desirable to set the common as being the size of the
     largest instance, even if an initilized version is under-size.

     Note that this is an area that systems implement differently.  It is 
     beneficial for star-cd to modify their code.

    	Well, I know that I've seen examples where the customer had
    a fine "working" program with mismatched common blocks.  These
    were nowhere initialized, so we happened to select the largest.
    So far so good.  Then, fate caused them to initialize (to zero)
    a single variable in what was a very large common block.  They
    happened to do this in a routine which did NOT have the common
    block defined to be as large as needed.  The linker then selected
    the "short" initialized version of the common block, and all h***
    broke loose.  I know - I got to debug the aftermath (do you suppose
    that they knew what had changed... or would tell me!?).
    
    	The moral of the story is to keep common blocks the same size
    everywhere.  To do otherwise is to invite problems - maybe not
    today, but sooner or later problems will come looking for you...
    
    Cheers!
    Dave Eklund
    

In .6, Mike Greenfield says:

>Most systems/environments pad out the commons to the largest
>instance and if we were not doing this, I suspect we would have lots of
> people noticing (and complaining).
...
>It still does seem desirable to set the common as being the size of the
>largest instance, even if an initialized version is under-size.

A Unix system that uses either the standard COFF or ELF object
language is unable to increase the size of an initialized COMMON at
link time.  Therefore, most Unix systems have this problem.

I once worked on a Unix system that used a nonstandard, extended ELF
so that the linker could detect that one of the modules defined a
COMMON block larger than the initialized version.  The linker was
unable to give the COMMON block the larger size but it could give a
warning.  The purpose of this warning to detect VAX Fortran compatible
programs that depended on this feature of the VAX/VMS linker and its
handling of psects.  Users still had to modify their COMMON definition
in order to get rid of the warning.

On Digital Unix, if you compile several Fortran modules together to
produce a single .o file, the compiler will maximize COMMON sizes
across all of these source files.  If you produce separate .o files
then there is nothing that Digital Fortran can do to force maximizing
the size of an initialized COMMON unless we adopt a .o file format
different from the  COFF or ELF standards.

RE: .6, .8

UNIX systems using the older a.out object file format can't do COMMON block size 
maximization if there is initialization, either.

Windows NT uses COFF and thus inherits this problem.

These days, systems that do it "right" are a distinct minority.  VMS and MVS are 
about the only ones I can think of.

--PSW

I understand that this is not a bug nor problem of digital. but Application 
vender who meet this problem want to have a single source code between its 
UNIX version and WindowsNT version  on both Alpha and Intel.

The application itself is very large and complex one. It seems that It is very 
difficult to change the all of the soruce code  for the vender.

Could you fix the liker to handle this problem as soon as possible?

If we can not fix this,They simply ship it only on Intel.
The name of this application is STAR-LT which is Nt version of Star-CD,one of 
famous CFD code(Computational Fluid dynamics code).
Its source code can be compiled successfully on major UNIX platfom including 
Alpha/UNIX and Intel/NT.


Best Regards
mamoru

>If we can not fix this,They simply ship it only on Intel.
>Its source code can be compiled successfully on major UNIX platfom including 
>Alpha/UNIX and Intel/NT.

Intel/NT and Alpha/NT <<BOTH>> use [MS]COFF so something here doesn't click.
Either it's a COFF limitation and thus cannot work on EITHER or it's
something else the user is hitting. Are you SURE that this really works
on Intel/NT ???

RE: .10

As Terry said in .11, if this application works on Intel NT but doesn't work on 
Alpha NT, then the problem is something other than COMMON block size allocation 
because Intel and Alpha NT both do that the same way.  And so does UNIX, for 
that matter.  I think something else is wrong here.

--PSW

   I read in a previous note that MS Powerstation Fortran got around some
   restrictions in the NT linker vis-a-vis 'large' common blocks
   by dynamically allocating large commons at run time.

   Could this have any bearing on this case?

   -- John Faricelli

>>   I read in a previous note that MS Powerstation Fortran got around some
>>   restrictions in the NT linker vis-a-vis 'large' common blocks
>>   by dynamically allocating large commons at run time.

Although we have heard rumors of FPS doing this, we can find no documentation on
how or when it's done... and simple examples don't happen automatically.  So
far, that doesn't explain it.

.10 says this application runs on Alpha/UNIX and Intel/NT.  If the link order
on Alpha/UNIX is the same as the link order on Alpha/NT, then both should see
this error.

.0 says they use Microsoft Fortran PowerStation on Intel/NT.  Since DVF/INT
replaces that now unsupported compiler, they need to try DVF.  The bad news is
that they should see the same problem on Intel that hey see on Alpha.  That's
not progress.

/Stan