Equivalence in Module

I have a problem equivalencing character variables of different lengths, where the longer (1024) is declared in the MODULE, and equivalenced to local character variables C11 and C2*2. The error message is not technically correct.

[FTN95/Win32 Ver. 5.40.0 Copyright (c) Silverfrost Ltd 1993-2009]

    PROCESSING MODULE  [<EDIT_PARAMETERS> FTN95/Win32 v5.40.0]
    NO ERRORS  [<EDIT_PARAMETERS> FTN95/Win32 v5.40.0]
0019)       EQUIVALENCE (XCOM,C1), (XCOM,C2)
*** Error 1029: This EQUIVALENCE would cause a redefinition of the USEd 
    variable XCOM
*** Error 1029: This EQUIVALENCE would cause a redefinition of the USEd 
    variable XCOM
    2 ERRORS  [<EXECUT> FTN95/Win32 v5.40.0]
*** Compilation failed

If I make the character variable in the module > 1024 (lencom) then the error report goes away ?? Is EQUIVALENCE allowed for modules ? Could the error test check if the equivalenced variables do not extend the declared length of the character in the module ?

I've cut down the following code to show the problem.

!     Last change:  JDC  24 Mar 2010    2:34 pm
module edit_parameters
!
      INTEGER*4, PARAMETER :: milion =    1000000   ! 1 million
      INTEGER*4, PARAMETER :: MAXSTR = 750*milion   ! max characters in file 750mb
      INTEGER*4, PARAMETER :: LENCOM =       1024   ! max characters in command
!
!    common variables
!
      character*1               CSTOR(MAXSTR)       ! text storage array
      character (len=lencom) :: XCOM                ! command line
end module edit_parameters

      SUBROUTINE EXECUT
!
USE edit_parameters
!
      CHARACTER C1*1, C2*2
      EQUIVALENCE (XCOM,C1), (XCOM,C2)
!
      IF (C2 == 'NL'.OR.C2 == 'nl') GOTO 601     ! not locate
      IF (C1 == 'N' .OR.C1 == 'n')  GOTO 601     ! next line
!
601   return
      end

What about using:

      EQUIVALENCE (XCOM(1:1),C1), (XCOM(1:2),C2)

is that allowed? Ian

Ian, I thought EQUIVALENCE merely set the memory address of the start of the variables to coincide, although it can be used to redefine the maximum size of a common block. I did find another error using EQUIVALENCE when converting to a module, where I previously equivalenced an array to a list of variables in a common block. The statement SEQNENCE appears to apply to a TYPE definition, but I don't know if there is any guarantee about the sequence of variables in a module agreeing with their memory order. Indeed, from my reading of the .map, larger variables in a module are stored in a different place in memory.

My error is equivalencing the defined variable in the module to smaller variables. It may be too much to ask and EQUIVALENCE is not allowed.

I did try your suggestion, but it gave the same error message.

John

John, regarding the sequence statement, have a look at the link: http://books.google.co.uk/books?id=AUx7vKIiuvwC&pg=PA82&lpg=PA82&dq=fortran+sequence+statement&source=bl&ots=OMwORgK_2l&sig=e2ZK0rP4qev-NXjJi9MZKqzNWic&hl=en&ei=DxurS7i-DpL-0gSag7GTDg&sa=X&oi=book_result&ct=result&resnum=5&ved=0CBUQ6AEwBA#v=onepage&q=fortran%20sequence%20statement&f=false

Third paragraph

Regards Ian

Ian, Thanks for that. It appears SEQUENCE is limited to TYPE structures. I don't know of any sequence assumptions that can be applied to a MODULE. My error relates to the use of C1 and C2 as an easier way of addressing the first 2 characters of a larger character variable XCOM*512. Although in this case, the use of EQUIVALENCE does not require any assumptions of order of variables in the module, the general rule of not being able to assume variable sequencing appears to be applied. I have a number of coding examples, where I have placed a list of variables in common and then used the first variable as the address and number of bytes in binary read/write routines to simplify the I/O. I don't think error 1029 should be applied in this case, inless I am missing something else. John

I will aim to have a look at this problem when I can but I have a back log of things to do at the moment.

It looks like it may be something to do with the way that the memory is allocatied by FTN95. If so then the behaviour may be different with and without /check.

I can see what is happening but I am not yet sure if a fix is needed.

As soon as your module string has length greater than 1024, FTN95 decides to store the string as it would in a COMMON block. This has something to do with good memory usage.

Now the equivalence works OK for a COMMON block hence no failure.

I do not know if MODULE storage allows for equivalence, i.e. does the standard permit this construction? Probably not. If it does then I guess that FTN95 should put smaller strings into COMMON when EQUIVALENCE is used. The problem is that the usage is not known when the module is created.

I hope that this addresses the problem and that you are happy that a fix to the compiler is probably not required.

Further to my comment above, this usage is not permitted by the Standard and is trapped by FTN95 when using /ISO on the command line.

In effect character variables of length greater than 1024 correspond to an FTN95 extension to the Standard.