This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix EQUIVALENCE vs. SAVE (PR fortran/18518)
- From: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- To: Richard E Maine <Richard dot Maine at nasa dot gov>
- Cc: Jakub Jelinek <jakub at redhat dot com>, gcc-patches at gcc dot gnu dot org, fortran at gcc dot gnu dot org
- Date: Tue, 27 Sep 2005 17:39:35 -0700
- Subject: Re: [PATCH] Fix EQUIVALENCE vs. SAVE (PR fortran/18518)
- References: <20050927212050.GB1020@devserv.devel.redhat.com> <ab9902bfa712ea5ca6887789d4967d57@nasa.gov>
On Tue, Sep 27, 2005 at 02:52:41PM -0700, Richard E Maine wrote:
> On Sep 27, 2005, at 2:20 PM, Jakub Jelinek wrote:
>
> There are a few things you can probably deduce based on the business
> about variables becoming defined/undefined when associated variables of
> the same type do. But unless I missed something, there are a few cases,
> (notably the few cases where variables of different types can be
> associated) where it looks to me like SAVEing one variable doesn't
> amount to SAVEing an equivalenced one (I think).
>
I'm beginning to dislike Chapter 14 of F95 (or Chapter 16 of F2003).
14.7.6 Events that cause variables to become undefined
Variables become undefined as follows:
(1) When a variable of a given type becomes defined, all
associated variables of different type become undefined. ...
subroutine t(y)
real x
integer i
save x,i
equivalence(x,i)
interface
subroutine foo(i, x, y)
integer, intent(in) :: i
real, intent(in) :: x
real, intent(inout) :: y
end subroutine foo
end interface
interface
subroutine bar(i, x, y)
integer, intent(in) :: i
real, intent(in) :: x
real, intent(inout) :: y
end subroutine bar
end interface
if (y < 0.) then
i = 0
!
! x is undefined?
!
call foo(i,x,y)
else
x = 1.
!
! i is undefined?
!
call bar(i,x,y)
end if
end
Is this conforming? That is, can an undefined variable
be used as an INTENT(IN) function argument. If it is
conforming, does it make sense?
--
Steve