yet another QUERRY on EQUIVALENCE Re: EQUIVALENCE(variable inside module, variable outside module) ????

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


Richard E Maine wrote:
> James Van Buskirk <not_valid@xxxxxxxxxxx> wrote:
> > For those of us who don't understand well the interaction
> > between MODULE, COMMON, and EQUIVALENCE, could you please
> > explain the behavior of this example with both the version
> > that compilers like and the version that compilers hate?
> >
> > module equiv_mod
> > implicit none
> > real x
> > common /equiv_mod_com/ x
> > end module equiv_mod
> >
> > program test
> > use equiv_mod
> > implicit none
> > integer i
> > ! equivalence (x, i) ! LF95, CVF, g95 all hate this
> > common /equiv_mod_com/ i ! LF95, CVF, g95 all like this
> >
> > x = 1.0
> > write(*,'(1x,z8.8)') i
> > end program test
> 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