equivalence croakage

[Hans Horn-2]

Folks,

just trying to make the switch from g77 to gfortran (and from gcc3 to gcc4).
When compiling some legacy f77 code that uses f77 equivalence
statements, I get barfed at with the following (32bit environment):

<During initialization>

Error: Overlapping unequal initializers in EQUIVALENCE at (1)

Doesn't tell at all where the shit is happening.

This code happens to compile with various f77 compilers (aix xlf, g77).

I collected all the equivalence statements from the offending f77 source
(all more or less variations of the same theme):

       subroutine dud
       IMPLICIT NONE
       Character cDummy(8)/8*' '/, CSTORE(8)/8*' '/, CSTORE1(8)/8*' '/
       Integer   iDummy(2), ISTORE(2), ISTORE1(2)
       Real*8    rDummy(1), XSTORE

       Equivalence(CSTORE(1),XSTORE,ISTORE)
       Equivalence(CSTORE1(1),ISTORE1)
       Equivalence(cDummy(1), iDummy(1), rDummy(1))

       end

this just happens to compile w/o a problem.

Am I being kicked by a gfortran bug?

Thx.,
H.

[Tobias Burnus]

Hans Horn wrote:
> just trying to make the switch from g77 to gfortran (and from gcc3 to
> gcc4).
> When compiling some legacy f77 code that uses f77 equivalence
> statements, I get barfed at with the following (32bit environment):

Which version of the compiler? It is compiled here with gfortran 4.1.2
up to 4.5.0(experimental) without any warning (default options).

With "-pedantic" I get:

Warning: Non-CHARACTER object 'xstore' in default CHARACTER EQUIVALENCE
statement at (1)

which is OK.

Tobias

[Tim Prince-4]

Hans Horn wrote:

>       subroutine dud
>       IMPLICIT NONE
>       Character cDummy(8)/8*' '/, CSTORE(8)/8*' '/, CSTORE1(8)/8*' '/
>       Integer   iDummy(2), ISTORE(2), ISTORE1(2)
>       Real*8    rDummy(1), XSTORE
>
>       Equivalence(CSTORE(1),XSTORE,ISTORE)
>       Equivalence(CSTORE1(1),ISTORE1)
>       Equivalence(cDummy(1), iDummy(1), rDummy(1))
>
>       end
>
> this just happens to compile w/o a problem.
>

It's somewhat surprising that you could compile this stuff with multiple
f77 compilers.  Not all f77 compilers support all the non-standard
extensions
(1) real*8
(2) EQUIVALENCE of character and non-character data types
(3) initialization in declaration under f77
So, what you have shown here are not f77 equivalence.  Surely, gfortran
should complain if you turned on standards checking.

The notations Error:  ....... at (1) generally refer to a previous
attempt to quote a source line and follow it with a line containing 1 in
the same column as the referenced problem.

[Steve Kargl]

On Sun, Nov 01, 2009 at 11:53:58AM -0800, Hans Horn wrote:

> Folks,
>
> just trying to make the switch from g77 to gfortran (and from gcc3 to gcc4).
> When compiling some legacy f77 code that uses f77 equivalence
> statements, I get barfed at with the following (32bit environment):
>
> <During initialization>
>
> Error: Overlapping unequal initializers in EQUIVALENCE at (1)
>
> Doesn't tell at all where the shit is happening.
>
> This code happens to compile with various f77 compilers (aix xlf, g77).
>
> I collected all the equivalence statements from the offending f77 source
> (all more or less variations of the same theme):
>
>       subroutine dud
>       IMPLICIT NONE
>       Character cDummy(8)/8*' '/, CSTORE(8)/8*' '/, CSTORE1(8)/8*' '/
>       Integer   iDummy(2), ISTORE(2), ISTORE1(2)
>       Real*8    rDummy(1), XSTORE
>
>       Equivalence(CSTORE(1),XSTORE,ISTORE)
>       Equivalence(CSTORE1(1),ISTORE1)
>       Equivalence(cDummy(1), iDummy(1), rDummy(1))
>
>       end
>
> this just happens to compile w/o a problem.
>
> Am I being kicked by a gfortran bug?
>

Please show the complete error message.
Please show the actual code causing the problem.
Please report the version of gfortran that you are using.
Please report the options that you used.

I doubt that it's a bug in gfortran.  I suspect it's a
bug in your code because using equivalence correctly is
actually more difficult than it may appear.

--
Steve

[Hans Horn-2]

Steve Kargl wrote:

> On Sun, Nov 01, 2009 at 11:53:58AM -0800, Hans Horn wrote:
>  
>> Folks,
>>
>> just trying to make the switch from g77 to gfortran (and from gcc3 to gcc4).
>> When compiling some legacy f77 code that uses f77 equivalence
>> statements, I get barfed at with the following (32bit environment):
>>
>> <During initialization>
>>
>> Error: Overlapping unequal initializers in EQUIVALENCE at (1)
>>
>> Doesn't tell at all where the shit is happening.
>>
>> This code happens to compile with various f77 compilers (aix xlf, g77).
>>
>> I collected all the equivalence statements from the offending f77 source
>> (all more or less variations of the same theme):
>>
>>       subroutine dud
>>       IMPLICIT NONE
>>       Character cDummy(8)/8*' '/, CSTORE(8)/8*' '/, CSTORE1(8)/8*' '/
>>       Integer   iDummy(2), ISTORE(2), ISTORE1(2)
>>       Real*8    rDummy(1), XSTORE
>>
>>       Equivalence(CSTORE(1),XSTORE,ISTORE)
>>       Equivalence(CSTORE1(1),ISTORE1)
>>       Equivalence(cDummy(1), iDummy(1), rDummy(1))
>>
>>       end
>>
>> this just happens to compile w/o a problem.
>>
>> Am I being kicked by a gfortran bug?
>>
>>    
>
> Please show the complete error message.
> Please show the actual code causing the problem.
> Please report the version of gfortran that you are using.
> Please report the options that you used.
>
> I doubt that it's a bug in gfortran.  I suspect it's a
> bug in your code because using equivalence correctly is
> actually more difficult than it may appear.
>
>  

Steve,

I was using gfortran v4.5 and this WAS the entire error message!

The legacy f77 code I was trying to compile was written in the early 90s.
I just fsplit the whole source file and compiled the bits.
Here's the offending subroutine:
ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc

     Subroutine RestoreR8Run(IPASS,ibtoi,ibtor,nbyte,NSTORE,
    &                        XOUT,CXIN,TP9MN,TMN)
     Implicit NONE
     Integer IPASS,ibtoi(4),ibtor(8),nbyte,NSTORE,IBC,I,ISTORE/0/
     Real*8  XOUT(NSTORE), TP9MN,TMN,            XSTORE
     Character CXIN(nbyte*NSTORE),     CSTORE(8)/8*' '/
     EQUIVALENCE                      (CSTORE(1),XSTORE,ISTORE)

     IBC = 1
     if (nbyte.le.4) then
       DO I = 1, NSTORE
         call RestoreNByte(ISTORE,ibtoi,nbyte,CXIN(IBC),.false.)
         IF (IPASS .EQ. 1) then
           XOUT(I) = XOUT(I) + ISTORE * TP9MN       ! ISTORE and XSTORE
are equivalenced
         else
           XOUT(I) = ISTORE * TMN
         endif
         IBC = IBC + nbyte
       enddo
     else
       DO I = 1, NSTORE
         CSTORE(ibtor(1)) = CXIN(IBC    )
         CSTORE(ibtor(2)) = CXIN(IBC + 1)
         CSTORE(ibtor(3)) = CXIN(IBC + 2)
         CSTORE(ibtor(4)) = CXIN(IBC + 3)
         CSTORE(ibtor(5)) = CXIN(IBC + 4)
         CSTORE(ibtor(6)) = CXIN(IBC + 5)
         CSTORE(ibtor(7)) = CXIN(IBC + 6)
         CSTORE(ibtor(8)) = CXIN(IBC + 7)
         XOUT(I) = XOUT(I) + XSTORE * TP9MN ! XSTORE and CSTORE are
equivalenced
         IBC = IBC + 8
       enddo
     endif

     end
ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc



commandline used:
gfc -c -Wuninitialized -Wunused-label -fno-underscoring -fno-f2c
-ffixed-line-length-132  -g -gstabs -O  -march=pentium4 -pipe -x
f77-cpp-input

When I remove the initialization of ISTORE/0/, it compiles - surprise.

Would be nice to get an error message that tells what's wrong.

H

[Steve Kargl]

On Sun, Nov 01, 2009 at 07:39:07PM -0800, Hans Horn wrote:

> >>
> >><During initialization>
> >>
> >>Error: Overlapping unequal initializers in EQUIVALENCE at (1)
> >>
> >>Doesn't tell at all where the shit is happening.
> >
> >Please show the complete error message.
> >Please show the actual code causing the problem.
> >Please report the version of gfortran that you are using.
> >Please report the options that you used.
> >
> >I doubt that it's a bug in gfortran.  I suspect it's a
> >bug in your code because using equivalence correctly is
> >actually more difficult than it may appear.
> >
> >  
>
> Steve,
>
> I was using gfortran v4.5 and this WAS the entire error message!

No, you did not show the entire error message.  If it includes
a locus, ie., 'EQUIVALENCE at (1)', then a line of code was spit
out.  That's part of the error message.

> commandline used:
> gfc -c -Wuninitialized -Wunused-label -fno-underscoring -fno-f2c
> -ffixed-line-length-132  -g -gstabs -O  -march=pentium4 -pipe -x
> f77-cpp-input
>

This isn't the exact command line.  There is no filename listed.

Drop the -fno-f2c.  It's not needed because it's the default.
Add '-Wall -std=f95', and fix any problems.  Why are you using
f77-cpp-input?


> When I remove the initialization of ISTORE/0/, it compiles - surprise.
>
> Would be nice to get an error message that tells what's wrong.
>

It would be nice if you actually wrote standard conforming Fortran.

--
Steve

[Tobias Burnus]

Hans Horn wrote:
> Steve Kargl wrote:
>> Please show the complete error message.
>> Please show the actual code causing the problem.
>> Please report the version of gfortran that you are using.
>> Please report the options that you used.
>>  
>
> I was using gfortran v4.5 and this WAS the entire error message!

It does not if you post complete code. As written before, the snippet of
code, which you posted before, works with gfortran.

> The legacy f77 code I was trying to compile was written in the early 90s.

Which does not mean that it is valid. As the error message of gfortran
indicates ("Overlapping unequal initializers in EQUIVALENCE") or the
warning of Open64 ("Warning: Multiple DATA initialization of storage for
.EQUIVA. Some initializations ignored."), your code has a problem:

You cannot initialize the same bit of storage by two different values -
it simply does not work. The compiler can either give an error (as
gfortran does), a warning (as Open64) or silently choose one of them for
initializing (as with ifort). I would argue that giving an error is
sensible, forcing the user to decide which initialization (s)he wants.

(There are several other features which make the code nonconforming to
the standard, but at least those extensions are non-ambiguous.)

> When I remove the initialization of ISTORE/0/, it compiles - surprise.

Why? You say that CSTORE(1), XSTORE and ISTORE share (at lease some of)
the bits as they are equivalenced.

You initialize "CSTORE(1)" with ' ' and ISTORE with 0 - what should the
compile now do? Use " "? Or "0" or one bit from CSTOR(1) followed by one
bit from ISTORE, followed by ... ?

> Would be nice to get an error message that tells what's wrong.
I would argue that the error message of gfortran and the warning of
Open64 are as clear as one get get. Or do you have a suggestion how the
error message can be improved?

Tobias

[Dominique Dhumieres]

With the code in http://gcc.gnu.org/ml/fortran/2009-11/msg00011.html
gfortran 4.2.4 gives

equiv_bad.f90:7.61:

    EQUIVALENCE                      (CSTORE(1),XSTORE,ISTORE)
                                                            1
Error: Initialized objects 'cstore' and 'istore' cannot both be in the EQUIVALENCE statement at (1)

which is much better than what I get with gfortran 4.3.4, 4.4.2, and trunk:

<During initialization>

Error: Overlapping unequal initializers in EQUIVALENCE at (1)

Dominique

[Tobias Burnus]

On 11/02/2009 01:30 PM, Dominique Dhumieres wrote:

> With the code in http://gcc.gnu.org/ml/fortran/2009-11/msg00011.html
> gfortran 4.2.4 gives
>
>     EQUIVALENCE                      (CSTORE(1),XSTORE,ISTORE)
>                                                             1
> Error: Initialized objects 'cstore' and 'istore' cannot both be in the EQUIVALENCE statement at (1)
> which is much better than what I get with gfortran 4.3.4, 4.4.2, and trunk:
>
> Error: Overlapping unequal initializers in EQUIVALENCE at (1)
>  

It might be more enlightening, but the error message of 4.1/4.2 is
misleading/wrong: cstore and istore may be both initialized - as long as
the initializer affects different bytes.

For instance, in the following program both i and j are (partially)
initialized. In this case the program is valid,* compiles and prints the
expected values. (gfortran 4.1/4.2 reject it.)

However, if all of "j" is initialized, there is an overlap and thus the
program is invalid:

integer :: i(2)
integer :: j(2)
data i(1)/5/
data j(2)/7/
!data j/1,1/
equivalence (i,j)
print *, i
print *, j
end

Tobias

(* Well, kind of. If one initializes "i(1)", strictly speaking accessing
"j(1)" is invalid as "j(1)" is not initialized; but I think many
utilizations of EQUIVALENCE rely on it. Otherwise, EQUIVALENCE would
just save memory and could not be used as TRANSFER replacement.
[TRANSFER is also ill defined, but is standard conform.])

[Dominique Dhumieres]

If I replace 'data j(2)/7/' with 'data j/1,1/' I get

equiv_bad_1.f90:3.11:

data i(1)/5/
           1
Error: Overlapping unequal initializers in EQUIVALENCE at (1)

which may lead the user to what's wrong (a double locus would be
more helpful). For the code in http://gcc.gnu.org/ml/fortran/2009-11/msg00011.html
the error is very unfriendly:

<During initialization>

Error: Overlapping unequal initializers in EQUIVALENCE at (1)

"<During initialization>" is generated when there is no known locus.
I find also "unequal" misleading: once you know what the problem is,
it is "unequal values for the same memory location(s)", but if
you don't know what's going wrong, you can think that it is the length
of the data, ... .

Dominique

[Hans Horn-2]

Tobias Burnus wrote:

> On 11/02/2009 01:30 PM, Dominique Dhumieres wrote:
>> With the code in http://gcc.gnu.org/ml/fortran/2009-11/msg00011.html
>> gfortran 4.2.4 gives
>>
>>     EQUIVALENCE                      (CSTORE(1),XSTORE,ISTORE)
>>                                                             1
>> Error: Initialized objects 'cstore' and 'istore' cannot both be in the EQUIVALENCE statement at (1)
>> which is much better than what I get with gfortran 4.3.4, 4.4.2, and trunk:
>>
>> Error: Overlapping unequal initializers in EQUIVALENCE at (1)
>>  
>
> It might be more enlightening, but the error message of 4.1/4.2 is
> misleading/wrong: cstore and istore may be both initialized - as long as
> the initializer affects different bytes.
>
> For instance, in the following program both i and j are (partially)
> initialized. In this case the program is valid,* compiles and prints the
> expected values. (gfortran 4.1/4.2 reject it.)
>
> However, if all of "j" is initialized, there is an overlap and thus the
> program is invalid:
>
> integer :: i(2)
> integer :: j(2)
> data i(1)/5/
> data j(2)/7/
> !data j/1,1/
> equivalence (i,j)
> print *, i
> print *, j
> end
>
> Tobias
>
> (* Well, kind of. If one initializes "i(1)", strictly speaking accessing
> "j(1)" is invalid as "j(1)" is not initialized; but I think many
> utilizations of EQUIVALENCE rely on it. Otherwise, EQUIVALENCE would
> just save memory and could not be used as TRANSFER replacement.
> [TRANSFER is also ill defined, but is standard conform.])
>

Tobias, Jerry, Steve, Dominique, Tim,

Thx y'all for your friendly and encouraging advice.

I managed to fix all compile and link errors. Some initial tests even
confirm that the binaries work!

Point is that I do NOT intend to make the gobs of old fortran
standard-compliant (just want it to compile and work on platforms I care
about), nor do I plan to write more new fortran code than absolutely
necessary.

greets,
H.

[Steve Kargl]

On Mon, Nov 02, 2009 at 05:39:23PM +0100, Dominique Dhumieres wrote:

> If I replace 'data j(2)/7/' with 'data j/1,1/' I get
>
> equiv_bad_1.f90:3.11:
>
> data i(1)/5/
>            1
> Error: Overlapping unequal initializers in EQUIVALENCE at (1)
>
> which may lead the user to what's wrong (a double locus would be
> more helpful). For the code in http://gcc.gnu.org/ml/fortran/2009-11/msg00011.html
> the error is very unfriendly:
>
> <During initialization>
>
> Error: Overlapping unequal initializers in EQUIVALENCE at (1)
>
> "<During initialization>" is generated when there is no known locus.
> I find also "unequal" misleading: once you know what the problem is,
> it is "unequal values for the same memory location(s)", but if
> you don't know what's going wrong, you can think that it is the length
> of the data, ... .
>

Yep.  This is related to the old-style g77 non-standard
initialization.  If the OP had used -Wall, he would have
had the opportunity to fix his poorly conformng code.

--
Steve