Accidental Equivalence

| SimCon Home | fpt Reference Manual Home |

Implied or Accidental Equivalence

Implied equivalence occurs when two or more different objects occupy the same memory address without being associated by a deliberate EQUIVALENCE statement or MAP construct (MAP constructs are non-standard). The issue usually occurs in COMMON blocks. Sometimes the implied equivalence is deliberate. Sometimes it is accidental.

Objects in COMMON blocks are packed in the strict order of their declaration in COMMON statements. The COMMON blocks are laid out separately in each sub-program where they are declared. A COMMON block will be laid out consistently, with no accidental equivalence if:

All the COMMON statements are written only in include files;
All of the COMMON variables, and all associated resource parameters, derived types and structures are declared only in include files;
The type and kind of every object is declared or the IMPLICIT regime is the same in every sub-program which uses the COMMON block.

This is the usual practice in setting out COMMON blocks in extended FORTRAN 77 legacy codes. However, sometimes the COMMON block orgaisation is written separately in two or more routines. In this case there is a risk of accidental equivalence.

Detecting Implied Equivalence

Implied equivalence is reported by the fpt command:

CHECK EQUIVALENCE

fpt reports all objects which occupy the same memory locations without explicit EQUIVALENCE statements or MAP constructs. Note that it is possible to report implied equivalence. The user must judge whether the equivalence is accidental.

The misaligned COMMON block shown in the game program TREK7 on the inconsistent names page is also trapped by the implied equivalence check. The end of the report, including the summary of results, is shown below:

COMMON n -------- Implied EQUIVALENCE Name Scope Use/COMMON Address Type Size Value/Bounds ---- ----- ---------- ------- ---- ---- ------------ iname mccoy,sauron,finney,knuth,tholia,dune,enemy,talos,balok,entemp,tpau, leguin... /n/ 0 INTEGER *4 df (1:3,1:4) iname moe,zeppo,chico,shadow,eccle /n/ 0 INTEGER *4 df (1:2,1:4) ienm2 moe,zeppo,chico,shadow,eccle /n/ 32 INTEGER *4 df (1:4,1:8) ******************** ienm2 moe,zeppo,chico,shadow,eccle /n/ 32 INTEGER *4 df (1:4,1:8) ienm2 mccoy,sauron,finney,knuth,tholia,dune,enemy,talos,balok,entemp,tpau, leguin... /n/ 48 INTEGER *4 df (1:4,1:8) ******************** ienm2 mccoy,sauron,finney,knuth,tholia,dune,enemy,talos,balok,entemp,tpau, leguin... /n/ 48 INTEGER *4 df (1:4,1:8) iside moe,zeppo,chico,shadow,eccle /n/ 160 INTEGER *4 df (1:2,1:2) ******************** iside mccoy,sauron,finney,knuth,tholia,dune,enemy,talos,balok,entemp,tpau, leguin... /n/ 176 INTEGER *4 df (1:3,1:2) ibase moe,zeppo,chico,shadow,eccle /n/ 176 INTEGER *4 df (1:2) ******************** COMMON t -------- Implied EQUIVALENCE Name Scope Use/COMMON Address Type Size Value/Bounds ---- ----- ---------- ------- ---- ---- ------------ ichos sauron,finney,blish,knuth,tholia,dune,moloch,enemy,talos,balok, entemp,quark... /t/ 16 INTEGER *4 df (1:8) ichos shadow /t/ 16 INTEGER *4 df (1:6) ichob shadow /t/ 40 INTEGER *4 df (1:2) ******************** No mixed or implied EQUIVALENCE detected in COMMON blocks: d, h, j, o, p, q, r, s, tom, u, v, w Check of Local Variables for Mixed EQUIVALENCE ---------------------------------------------- No EQUIVALENCE of mixed type or size detected ------------------------------------------------------------------------------- !!! EQUIVALENCE Check !!! !!! Total number of mixed or implied EQUIVALENCE (Warnings): 56 -------------------------------------------------------------------------------