Severe Bug with EQUIVALENCE

The following code is working fine if compiled with 32-bit FTN95 version.

MODULE  XXX
      :
INTEGER, PARAMETER :: LENAMBUF = 50000
      :
REAL*8       APF (LENAMBUF/2-1) and indices
INTEGER      IPF (2,LENAMBUF/2-1)
EQUIVALENCE  (APF(1), IPF(1,1))
      :
END MODULE XXX
!------------------------------------------------------

Subroutine YYY
    USE XXX
      :
    IPF (1,IPI+1) = iType
    IPF (2,IPI+1) = No1
    IPF (1,IPI+2) = No2
    IPF (2,IPI+2) = No3
    IPF (1,IPI+3) = No4
    IPF (2,IPI+3) = nCoefficients
    APF (IPI+4)   = ObservationL
    APF (IPI+5)   = ObservLzero
    APF (IPI+6)   = WeightP
      :
    Write APF to disk
      :
END Subroutine YYY
!------------------------------------------------------

Subroutine ZZZ
    USE XXX
      :
    Read APF from disk
      :
    iObservType   = IPF (1,IPI+1)
    No1           = IPF (2,IPI+1)
    No2           = IPF (1,IPI+2)
    No3           = IPF (2,IPI+2)
    No4           = IPF (1,IPI+3)
    nCoefficients = IPF (2,IPI+3)
    ObservationL  = APF (IPI+4)
    ObservLzero   = APF (IPI+5)
    WeightP       = APF (IPI+6)
      :
END Subroutine ZZZ

Copiling with /64 option it goes completele wrong. I cannot get my data back. If I remove the APF / IPF part from Module XXX and introduce the following COMMON in all related Subroutines, everything is working correct in 32-bit and in 64-bit versions.

    REAL*8       APF (50000/2-1)
    INTEGER      IPF (2,50000/2-1)
    EQUIVALENCE  (APF(1), IPF(1,1))
    COMMON /AMBUF/ APF

My only explanation is that EQUIVALENCE is not working. Please see as well my last post in section General.

Thank you for the feedback. I have logged this as needing attention.

Unfortunately I cannot continue development with FTN95 /64 as long as there is this bug. Is there a perspective to get this solved soon?

Erwin,

I thought EQUIVALENCE is not allowed in a MODULE in F90 or F95 ? It is a structure for local or COMMON arrays only.

The Lahey F95 manual I have also requires: 'If an equivalence-object is of an intrinsic type other than default INTEGER, default REAL, double precision REAL, default COMPLEX, default LOGICAL, or default CHARACTER, all of the objects in equivalence-set must be of the same type with the same kind value.' This sounds a bit restrictive, as I have certainly mixed kind values for non default types. I typically EQUIVALENCE real8 and integer4 arrays in COMMON, without any problems for 32-bit or 64-bit. I am not sure of the example you have provided.

John

John, do you know any documentation about this? I'm using this since long time. Erwin

Section 5.5.1 of F95 standard excludes 'an automatic object' and 'a structure component'. An earlier example you gave was an automatic object. I am not sure if a structure component excludes a component of a MODULE ? Note 11.8 in Section 11.3.2 excludes the use of a local name in a USE statement from appearing in EQUIVALENCE. You are wanting to equivalence two specification statements in a MODULE. I can't find a comment on this, although in general you can't assume any order in a MODULE, or if the specified components are ordered. I have never used EQUIVALENCE in a MODULE.

John

Erwin

I am not able to promise a quick fix but it would be a great help if you could post a short working program that works in 32 bit mode and illustrates the problem.

Paul,

I reproduced a test which I thought failed years ago with /32, but it now appears to work ? ( ftn95 test.f90 /link /map ) The .exe is huge. It does however fail with /64 ( ftn95 test.f90 /64 /link /map ) ! Last change: JDC 11 Feb 2002 10:18 pm ! INCLUDE 'sapmem.ins' working storage definition ! module sapmem integer4, parameter :: one_mb_8 = 10241024/8 !z INTEGER4, PARAMETER :: MXTOT = 1300one_mb_8 ! working storage size R8 INTEGER4, PARAMETER :: MXTOT = 130one_mb_8 ! working storage size R8 INTEGER4, PARAMETER :: M4TOT = MXTOT2 ! working storage size I4 ! !z COMMON /SAPCM1/ MTOT, P_END INTEGER4 MTOT, P_END ! !z COMMON /SAPCM9/ AABASE REAL8 AABASE(MXTOT) INTEGER4 IIBASE(M4TOT) EQUIVALENCE (AABASE,IIBASE) ! end module sapmem

  use sapmem
     
   integer*4 ii
!
   write (*,*) 'aabase at',loc (aabase)
   write (*,*) 'iibase at',loc (iibase)
   do ii = 1,mxtot
     aabase(ii) = ii
   end do
   end   

Thanks John.

A preliminary investigation may lead to a work-around. Any fix would probably require a full release or a full intermediate release.

Paul, I have isolated the problem, but I cannot place it in the forum. May I send it to your personnel email address?

John, using COMMON areas in combination with EQUIVALENCE I have correct results in 32- and in 64-bit versions. However, I do not use COMMON at all anymore, because it cannot hold dynamic arrays and cannot be included in DLLs. I am not sure about the memory usage; stack ...

Erwin

Erwin

This bug appears to arise when LENAMBUF/2-1 is an odd number. So a temporary work-around would be to use:

    INTEGER, PARAMETER :: LENAMBUF = 50000
    REAL*8      APF (LENAMBUF/2)
    INTEGER     IPF (2,LENAMBUF/2)

I will report this as a bug that needs fixing.

The results for 32 bit and 64 bit mode diverge at a late point in the calculations but I am assuming that this is a different issue.

Paul, back in the office I tested the program with a even number. However, I cannot see any difference !? Erwin

Erwin

It failed for me with an odd value and worked OK with an even value. This makes some sense if it is an alignment issue but there may still be a random element.

Are you sure that the code that you sent to me fails with an even value for N in IPF (2,N)?

Paul, I tried again and I am really sure that the even number did not make any difference. As well I don't understand why in 64-bit version only the last record will be read. Erwin

Erwin

My test program for this issue now works correctly. After the next full release, please let me know if this problem remains.