yet another QUERRY on EQUIVALENCE Re: EQUIVALENCE(variable inside module, variable outside module) ????
- From: "kis" <kisitanggang@xxxxxxxxx>
- Date: 8 Dec 2005 01:09:40 -0800
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@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
.
- Follow-Ups:
- References:
- EQUIVALENCE(variable inside module, variable outside module) ????
- From: kis
- Re: EQUIVALENCE(variable inside module, variable outside module) ????
- From: Richard Maine
- Re: EQUIVALENCE(variable inside module, variable outside module) ????
- From: James Van Buskirk
- Re: EQUIVALENCE(variable inside module, variable outside module) ????
- From: Richard E Maine
- EQUIVALENCE(variable inside module, variable outside module) ????
- Prev by Date: Re: Ten Commandments (On Topic!)
- Next by Date: Re: yet another QUERRY on EQUIVALENCE Re: EQUIVALENCE(variable inside module, variable outside module) ????
- Previous by thread: Re: EQUIVALENCE(variable inside module, variable outside module) ????
- Next by thread: Re: yet another QUERRY on EQUIVALENCE Re: EQUIVALENCE(variable inside module, variable outside module) ????
- Index(es):
Relevant Pages
|
