Very Basic question from Newbie

Hi all,
I am not able figure what the following compilation error means?I am
using g77 compiler and the error message is
"output_file.f: In subroutine `state':
output_file.f:1:
SUBROUTINE STATE(NRSTAT,ARRAY,TIME)
1
output_file.f:6: (continued):
EQUIVALENCE (ARRAY(1),X)
2
Invalid declaration of or reference to symbol `array' at (2) [initially
seen at (1)]"

The program is
SUBROUTINE STATE(NRSTAT,ARRAY,TIME)
REAL*8 ARRAY(9)
REAL*8 X, A, B, C, D, A1, B1, C1, D1
EQUIVALENCE (ARRAY(1),X)
EQUIVALENCE (ARRAY(2),A)
EQUIVALENCE (ARRAY(3),B)
EQUIVALENCE (ARRAY(4),C)
EQUIVALENCE (ARRAY(5),D)
EQUIVALENCE (ARRAY(6),A1)
EQUIVALENCE (ARRAY(7),B1)
EQUIVALENCE (ARRAY(8),C1)
EQUIVALENCE (ARRAY(9),D1)
REAL*8 TIME
DATA XNDA /4H"NDA/
DATA BLANK/4H"   /
GO TO 1000
2 x=A+B
RETURN
32 x=A*B
RETURN
3 x=A/B
RETURN
4 x=A+B+C
RETURN
1000 GO TO ( 100,  2,  3,   4,100,100,100,100,100,100,100,100,100,10
0,
 1100,100,100,100,100,100,100,100,100,100
,100,100,100,100,100,100,
2100, 32,
1 100),NRSTAT
100 X = XNDA
RETURN
C     THE FOLLOWING CODE IS EXECUTED AT THE BEGINNING OF EACH CONDITION
ENTRY GINITL
112 x=A-B
RETURN
END

Desperately waiting for the soultion.
Thanks in Advance

vashwath@rediffmail.com wrote:
>
> Hi all,
> I am not able figure what the following compilation error means?I am
> using g77 compiler and the error message is
>  "output_file.f: In subroutine `state':
> output_file.f:1:
>          SUBROUTINE STATE(NRSTAT,ARRAY,TIME)
>                                  1
> output_file.f:6: (continued):
>          EQUIVALENCE (ARRAY(1),X)
>                       2
> Invalid declaration of or reference to symbol `array' at (2) [initially
> seen at (1)]"
>

That is a pretty obsolete style of coding you have there ... consider
moving to some more modern fashion ;).

But to answer your original question: you can not use EQUIVALENCE on
a dummy argument - the reason is that the dummy argument will probably
refer to different actual arguments in the program. As the EQUIVALENCE
statement makes sure that memory locations can be accessed by different
names, this makes no sense for dummy arguments!

(EQUIVALENCE is not a run-time facility, but a compile-time. That is
it takes effect when compiling the program. It is not a general
aliasing mechanism. If you need that, consider moving to Fortran 90
and there are plenty of other reasons to do that anyway)

Regards,

Arjen

Hi,

vashwath@rediffmail.com wrote:

> Hi all,
> I am not able figure what the following compilation error means?I am
> using g77 compiler and the error message is
>  "output_file.f: In subroutine `state':
> output_file.f:1:
>          SUBROUTINE STATE(NRSTAT,ARRAY,TIME)
>                                  1
> output_file.f:6: (continued):
>          EQUIVALENCE (ARRAY(1),X)
>                       2
> Invalid declaration of or reference to symbol `array' at (2) [initially
> seen at (1)]"
>
> The program is
>       SUBROUTINE STATE(NRSTAT,ARRAY,TIME)
>       REAL*8 ARRAY(9)
>       REAL*8 X, A, B, C, D, A1, B1, C1, D1
>       EQUIVALENCE (ARRAY(1),X)
>       EQUIVALENCE (ARRAY(2),A)
>       EQUIVALENCE (ARRAY(3),B)
>       EQUIVALENCE (ARRAY(4),C)
>       EQUIVALENCE (ARRAY(5),D)
>       EQUIVALENCE (ARRAY(6),A1)
>       EQUIVALENCE (ARRAY(7),B1)
>       EQUIVALENCE (ARRAY(8),C1)
>       EQUIVALENCE (ARRAY(9),D1)

First comment : Yuck
Second comment: Double yuck

Third, and possibly useful comment: You are not allowed to equivalence an ar
gument
with anything. Essentially the compiler has to know at compile time what is 
being
equivalenced, and as an argument can come from anywhere it can't do this. Si
mplest
solution is to replace all the references to X with ARRAY( 1 ), A with ARRAY
( 2 )
etc., but given the following:


>       REAL*8 TIME
>       DATA XNDA /4H"NDA/
>       DATA BLANK/4H"   /
>       GO TO 1000
>     2 x=A+B
>       RETURN
>    32 x=A*B
>       RETURN
>     3 x=A/B
>       RETURN
>     4 x=A+B+C
>       RETURN
>  1000 GO TO ( 100,  2,  3,   4,100,100,100,100,100,100,100,100,100,10
0,
>       1100,100,100,100,100,100,100,100,100,100
,100,100,100,100,100,100,
>      2100, 32,
>      1 100),NRSTAT
>   100 X = XNDA
>       RETURN

I think a rewrite might be in order !

> C     THE FOLLOWING CODE IS EXECUTED AT THE BEGINNING OF EACH CONDITION
>       ENTRY GINITL
>   112 x=A-B
>       RETURN
>       END

And how the hell does this work ? X, A and B are equivalenced to something t
his
entry knows nothing about !

Hope this helps, and I think you need it given the above,

Ian

I have never understood why a dummy argument cannot be EQUIVALENCEd.

Consider:
SUBROUTINE SUB ( X )
REAL X
INTEGER I
EQUIVALENCE ( I, X )
etc.

Consider the first two lines only; this means that all references to X
will look at the appropriate location (probably on the stack) for the
address of X.
The second two lines merely tell the compiler that all references to I
should look at the same location.

Ignoring the (deliberate) mixed equivalencing, the same effect could be
achieved by:
REAL Y
CALL SUB ( Y, Y )
.
.
.
SUBROUTINE SUB ( X, I )
REAL X
INTEGER I

Which is legal

David Flower wrote:
> I have never understood why a dummy argument cannot be EQUIVALENCEd.
>
> Consider:
>       SUBROUTINE SUB ( X )
>       REAL X
>       INTEGER I
>       EQUIVALENCE ( I, X )
> etc.
>
> Consider the first two lines only; this means that all references to
X
> will look at the appropriate location (probably on the stack) for the
> address of X.
> The second two lines merely tell the compiler that all references to
I
> should look at the same location.
>
> Ignoring the (deliberate) mixed equivalencing, the same effect could
be
> achieved by:
> REAL Y
> CALL SUB ( Y, Y )
> .
> .
> .
> SUBROUTINE SUB ( X, I )
> REAL X
> INTEGER I
>
> Which is legal

Suppose that you are not passing two pointers to Y above, but instead
the subroutine is copy-in, copy-out. Then you can not predict what will
happen.

Modify X - and Y might change - depending on the order in which each
copy of Y is returned.

I don't quite understand you - are you suggesting a call by value
scenario ?

glen herrmannsfeldt wrote:

> David Flower wrote:
> 
> 
> 
>
> There is no technical reason, but mostly historical reasons.

Well on some implementations there could be alignment issues, i.e. the
argument is type has less stringent alignment restrictions than what
is being equivalenced to it,

Ian

Ian Bush wrote:

> glen herrmannsfeldt wrote:

(snip regarding EQUIVALENCE of dummy arguments)
 

> Well on some implementations there could be alignment issues, i.e. the
> argument is type has less stringent alignment restrictions than what
> is being equivalenced to it,

There could be alignment issues with COMMON and EQUIVALENCE,
traditionally COMMON being the cause of alignment problems.

As far as I know, the user is responsible for any alignment problems,
the compiler will generate the code as requested.

REAL A(10)
DOUBLE PRECISION D(4)
EQUIVALENCE (A(2),D(1))

may generate illegal alignment for access to D.  It may run
slow, or may fail completely.

-- glen

In article <-4WdnTIbjeZAFBXfRVn-jg@comcast.com>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> There could be alignment issues with COMMON and EQUIVALENCE,
> traditionally COMMON being the cause of alignment problems.
>
> As far as I know, the user is responsible for any alignment problems,

Well..... as the saying goes... "In theory there is no difference
between theory and practice, but in practice, there is." In this case,
I'd agree that in practice the user "is responsible for" (I might words
it as "gets stuck with") dealing with alignment problems. However, I
feel obligated to note that in theory (i.e. per the standard), this is
the compiler's responsibility.

> the compiler will generate the code as requested.
>
>         REAL A(10)
>         DOUBLE PRECISION D(4)
>         EQUIVALENCE (A(2),D(1))
>
> may generate illegal alignment for access to D.  It may run
> slow, or may fail completely.

This code is perfectly standard conforming (assuming it to be in an
otherwise valid context - for example, not dummy arguments involved, no
extension of the beginning of common blocks, etc.).

If it fails completely, then the compiler violates the standard.

However, there happen to be a lot of compilers that violate the standard
on this point. Plus, some of those that do handle this generate code
that runs very slowly, which doesn't violate the standard, but is likely
to be of concern to users in many cases. It is an unfortunate fact of
life that current hardware doesn't deal well with the implications of
this kind of construct. The compiler can work around the hardware
issues, but those workarounds tend to have horrible performance. So in
practice, yes, the user needs to worry about it.

The newer constructs of f90 and later place fewer constraints on memory
layout and are thus generally more suitable to tuning to hardware
alignment constraints without manual twiddling by the user. Equivalence
and common are bad that way. Of course, I'm severely overgeneralizing
here; there are times when users still need such manual twiddling. There
are compilers that do what I consider to be a poor job, forcing the
users to twiddle in cases where I claim that the compiler should handle
it. In particular, there are compilers that naively implement derived
types in ways that require the user to tweak alignment; I don't think
there is much "excuse" for compilers doing this for nonsequence types.
Admitedly, it has been a while since I've heard about this problem.
Perhaps the "guilty" compilers either got fixed or dropped from the
market.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain