Fortran - yet another QUERRY on EQUIVALENCE Re: EQUIVALENCE(variable inside module, variable ou

Author

yet another QUERRY on EQUIVALENCE Re: EQUIVALENCE(variable inside module, variable ou

kis

2005-12-08, 3:58 am

As this discussion is evolving, here is yet another simple question
with our "old friend" equivalence which is NOT related with module
(this time). I try this one:

program equiv_test

real :: a(4),b(2),c,d
equivalence (a(1:2),b),(a(3),c),(a(4),d)
..
..
..
end program equiv_test

And I got this error message when compiling it using CVF6.6.

C:\TEST\equivalence\equivalence.f(2) : Error: This operator is invalid
in a constant expression evaluation.
equivalence (a(1:2),b),(a(3),c),(a(4),d)

Any suggestion to resolve the problem???

Kind help is appreciated

Irfan

Richard E Maine wrote:
> James Van Buskirk <not_valid@comcast.net> wrote:
>
>
> I'll make a brfief attempt at explanation. I'm slightly rushed for time,
> but then again perhaps that will have the desirable effect of cutting
> down a little on my verbosity. :-)
>
> The situation with common is really quite simple, once you realize one
> critical point: that common blocks are not accessible via USE
> association. You are probably going to object that common blocks appear
> to be accessible, because you probably missed a slightly subtle
> distinction (many people do). The variables in the common block may be
> accessible, but the common block itself is not; that distinction is
> critical to the understanding.
>
> Thus, in your example that works, the USE statement gets access to a
> variable named i, but the fact that the variable happens to be in a
> common block is just an implementation detail that is not visible via
> the USE statement; the main program has no information about a common
> block being involved. Thus it is perfectly fine for the main program to
> have a common block named equiv_mod. And then common blocks work just
> like common blocks always have - the common block in the main program
> uses the same storage as any common block of the same name elsewhere.
>
> You would not be able to have a variable named x in a common block in
> the main program, and also import a variable named x via USE. But that's
> nothing special about common. That is just an illustration that common
> is *NOT* special in this regard. You can't ever import a name via USE
> and also declare something else of that same name.
>
> The only thing that is in the least bit "unusual" here is that you end
> up with two different names that access the same storage...and this
> isn't necessarily obvious at compile time. But there are other ways to
> get that same kind of issue. This isn't even new to f90 (or f77). For
> example, you can have an f77 (or even f66, or earlier) main program and
> subroutine, both of which have the same common block, and hav ethe main
> program pass a variable from that common block as an actual argument to
> the subroutine. The standard says that this is fine, except that the
> user is not allowed to modify the value of either variable in that case;
> this is one of those restrictions that the compiler isn't required to
> catch - indeed the whole point of the restriction is to give the
> compiler leeway for optimizations that would otherwise be hindered.
> Things are different if pointers are involved, as it is a basic property
> of pointer targets that they might be accessed via multiple pointers, so
> the compiler has to handle that (even when it hinders optimization).
>
> I'm running out of time, so I'll have to be a bit brief in treating
> equivalence. The main story here is twofold:
>
> 1. Equivalence is always local to a particular scoping unit. You can't
> ever equivalence things from different scoping units. For example, if
> you have a main program and an internal procedure, the internal
> procedure can't equivalence to a variable host-associated from the main
> program - if you try to, you'll find that you accidentally created an
> implicitly typed variable local to the internal procedure (unlesss, of
> course, you have implicit none, in which case it should fail
> compilation). The restriction of equivalence to be local is historically
> quite strong, even extending to a prohibition against equivalence
> involving dummy arguments. The dummy argument thing has beeen discussed
> here before. There is no compelling reason that I know of why
> equivalence couldn't be used with dummy arguments (given some obvious
> restrictions), but historically, it hasn't been.
>
> 2. There is a broad principle that all the properties of a module entity
> are defined in the module. You can't USE the module and then specify
> additional things about the module entities in the place where you USE
> it. There are a small number of special-case exceptions, and they
> basically amount to attributes that aren't really about the original
> entity, but are addditional restrictions on its use. Equivalence doesn't
> fall in that category.
>
> Note that if equivalence to module variables was allowed outside of the
> module, there would have top be a bunch of restrictions for it to make
> any sense at all. Notably, you can't expect to be able to equivalence a
> module variable to another module variable (in the same or different
> module) or anything in common. Both of those things would inherently
> involve specifying things about where the module variable was stored;
> USEing scoping units don't get to specify that about things that they
> use.
>
> Thus, you'd need several new restrictions to make such a thing work at
> all. I don't think that the general mood was to spend a lot of work
> extending equivalence in f90 when modules were introduced. Heck, teh
> required conditions are probably similar to those that would have beeen
> needed for equivaleence to dummy arguments. If equivalence to dummy
> arguments wasn't allowed before, why would the committee have gone out
> of its way to allow equivalence with module variables, which has some of
> the same kind of issues? Certainly it could have been done (I think),
> but I don't think that extensions to equivalence were high on the
> priority list. Phasing out equivalence was much higher on the priority
> list of some people, but that was controversial and never got into a
> published standard; you can see signs of it, however, in pointed
> omisssions in "obvious" opportunities to extend equivalence into some
> new features.
>
> --
> 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

Sponsored Links