[J3] Self-assignment of allocatable component
Daniel C Chen
cdchen at ca.ibm.com
Tue Jul 27 14:27:25 UTC 2021
Hi Malcolm,
Thanks for the explanation and the pointer to the Interp.
Just want to confirm one more thing that if the allocatable component
itself is of a derived type that has finalisation routine, I would think
the finalisation routine would be called, correct?
Thanks,
Daniel Chen
XL Fortran Development, Fortran Standard Representative
IBM Toronto Software Lab
Phone: 905-413-3056
Tie: 969-3056
Email: cdchen at ca.ibm.com
From: "Malcolm Cohen via J3" <j3 at mailman.j3-fortran.org>
To: "'General J3 interest list'" <j3 at mailman.j3-fortran.org>
Cc: "Malcolm Cohen" <malcolm at nag-j.co.jp>
Date: 2021-07-26 09:41 PM
Subject: [EXTERNAL] Re: [J3] Self-assignment of allocatable component
Sent by: "J3" <j3-bounces at mailman.j3-fortran.org>
Hi Daniel, Changing the allocation status of a component is absolutely a
definition of the variable. It changes its value! What could be more like a
definition! (If it were not a definition, that would be very problematic as
there would be
Hi Daniel,
Changing the allocation status of a component is absolutely a definition of
the variable. It changes its value! What could be more like a definition!
(If it were not a definition, that would be very problematic as there would
be a way of changing a variable without defining it (in the variable
definition sense), which would not make any sense.)
I don’t disagree in principle that some wording could be clearer, but I am
not seeing any ambiguity here.
I will also note that p15 says “(2) If the component of the value of expr
is allocated,”; note carefully that it talks about the value of expr here,
not expr itself as if it were an object. Seriously, this part is important
too.
Penultimately, I note that p15 says how the “definition” part of the
assignment statement is carried out. There is no doubt about this as it
does not talk about evaluating the expression at all – because that was
established right from the start.
Anyway, this whole question was settled years ago, this very question was
an interp request on Fortran 2003, and we changed the wording which indeed
was originally ambiguous. Here is that interp request.
Cheers,
----------------------------------------------------------------------
NUMBER: F03/0006
TITLE: Intrinsic assignment and allocatable components
KEYWORDS: assignment, allocatable
DEFECT TYPE: Erratum
STATUS: Included in F03 corrigendum 1
QUESTION:
Consider the following code:
type t
integer, allocatable :: i
end type
type(t) :: x
allocate(x%i)
x = x
print *, allocated(x%i)
end
In the intrinsic assignment, it is unclear whether the value of
the expression on the right-hand side of the assignment should be
determined before the any part of the left-hand side becomes
defined.
Section 7.4.1.3 of Fortran 2003 states:
The execution of the assignment shall have the same effect as
if the evaluation of all operations in <expr> and <variable>
occurred before any portion of <variable> is defined by the
assignment.
In this case, there are no operations in <expr>, so this sentence
does not apply. There doesn't appear to be anything else to
cover this situation, so it appears that in this case, <expr>
does not have to be evaluated before any part of <variable> is
defined.
If x%i becomes deallocated before the <expr> is evaluated, then
the call to the ALLOCATED intrinsic in this example would return
the value .false. Was it intended that this program could print
"F"?
ANSWER:
No. It was intended that the <expr> in an intrinsic assignment
must be evaluated before any part of the <variable> is defined.
An edit is supplied to correct this oversight.
EDITS:
All edits refer to 04-007.
[139:17] Change "the evaluation of all operations in <expr> and
<variable>" to "the evaluation of <expr> and the
evaluation of all expressions in <variable>".
[141:20,21,22] Before "<expr>" insert "the value of", thrice.
SUBMITTED BY: Rob James
HISTORY: 04-331 m169 Submitted F003/0006
04-331r1 m169 Passed by J3 meeting
04-418r1 m170 Passed J3 letter ballot #9
05-180 m172 Passed by WG5 ballot N1617
05-182r1 m172 Added to F03 Corrigendum 1 N1636
----------------------------------------------------------------------
Cheers,
--
..............Malcolm Cohen, NAG Oxford/Tokyo.
From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Daniel C Chen via
J3
Sent: Tuesday, July 27, 2021 9:26 AM
To: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Daniel C Chen <cdchen at ca.ibm.com>
Subject: Re: [J3] Self-assignment of allocatable component
Hi Malcolm,
What confuses me is the wording I quoted when the standard specifies the
intrinsic assignment for an allocatable component. It says:
"For a noncoarray allocatable component the following sequence of
operations is applied."
I suppose the following should be executed first.
"(1) If the component of the variable is allocated, it is deallocated."
It is not clear to me if the evaluation of expr should occur prior to this
deallocation although your explanation indicates so. The wording you quoted
only says "...occurred before any portion of the variable is defined by the
assignment." The deallocation doesn't seems definition of the variable to
me.
If that is the intention, should we at least add a Note to make it clearer?
Thanks,
Daniel Chen
XL Fortran Development, Fortran Standard Representative
IBM Toronto Software Lab
Phone: 905-413-3056
Tie: 969-3056
Email: cdchen at ca.ibm.com
Inactive hide details for "Malcolm Cohen via J3" ---2021-07-26 07:50:37
PM---No, the value assigned (and thus the effective “R"Malcolm Cohen via
J3" ---2021-07-26 07:50:37 PM---No, the value assigned (and thus the
effective “RHS component”) is unaffected by the variable on the
From: "Malcolm Cohen via J3" <j3 at mailman.j3-fortran.org>
To: "'General J3 interest list'" <j3 at mailman.j3-fortran.org>
Cc: "Malcolm Cohen" <malcolm at nag-j.co.jp>
Date: 2021-07-26 07:50 PM
Subject: [EXTERNAL] Re: [J3] Self-assignment of allocatable component
Sent by: "J3" <j3-bounces at mailman.j3-fortran.org>
No, the value assigned (and thus the effective “RHS component”) is
unaffected by the variable on the LHS. This is the general rule that the
value of the RHS is unaffected by the assignment to the LHS. Otherwise you
would be arguing that
No, the value assigned (and thus the effective “RHS component”) is
unaffected by the variable on the LHS. This is the general rule that the
value of the RHS is unaffected by the assignment to the LHS.
Otherwise you would be arguing that
REAL x(10)
...
X(2:) = X(:9)
would propagate the value of X(1) to the rest of X. That is not what
happens, and not what the standard says happens.
Fortunately the standard is pretty clear
“The execution of the assignment shall have the same effect as if the
evaluation of expr and the evaluation of all expressions in variable
occurred before any portion of the variable is defined by the assignment.”
Basically, the expression just delivers a value, whether the expression is
a reference to a variable or not. If the expression is a variable that *
might* overlap in some way with the LHS, the processor needs to capture the
value of the expression before beginning the writing part of the
assignment.
In the quoted example, there are no defined assignments going on, so the
processor is free to omit all actions! It can see that capturing the value
of P and then assigning that value to P will produce the same result as
just leaving P alone.
That is, Vipul is 100% correct that (absent defined assignments, as those
are procedure calls) assignment is equivalent to capturing the value of the
expression in a temporary, then doing the assignment from the temporary to
the variable. Fortran has *always* been like this, since the very beginning
way back in Fortran 66 where overlapping assignments could happen with
COMPLEX variables.
Cheers,
--
..............Malcolm Cohen, NAG Oxford/Tokyo.
From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Daniel C Chen via
J3
Sent: Tuesday, July 27, 2021 5:17 AM
To: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Daniel C Chen <cdchen at ca.ibm.com>
Subject: Re: [J3] Self-assignment of allocatable component
Hi Vipul,
My understanding is that the paragraph you quoted is AFTER (1), deallocate
LHS component, and (2), allocate LHS component based on RHS. Because Step
(1) already makes the RHS component unallocated, the rest actions are void.
Thanks,
Daniel Chen
XL Fortran Development, Fortran Standard Representative
IBM Toronto Software Lab
Phone: 905-413-3056
Tie: 969-3056
Email: cdchen at ca.ibm.com
Inactive hide details for "Vipul Parekh via J3" ---2021-07-26 04:10:32
PM---On Mon, Jul 26, 2021 at 3:17 PM Daniel C Chen via J"Vipul Parekh via
J3" ---2021-07-26 04:10:32 PM---On Mon, Jul 26, 2021 at 3:17 PM Daniel C
Chen via J3 < j3 at mailman.j3-fortran.org> wrote:
From: "Vipul Parekh via J3" <j3 at mailman.j3-fortran.org>
To: "General J3 interest list" <j3 at mailman.j3-fortran.org>
Cc: "Vipul Parekh" <parekhvs at gmail.com>
Date: 2021-07-26 04:10 PM
Subject: [EXTERNAL] Re: [J3] Self-assignment of allocatable component
Sent by: "J3" <j3-bounces at mailman.j3-fortran.org>
On Mon, Jul 26, 2021 at 3:17 PM Daniel C Chen via J3 <
j3 at mailman.j3-fortran.org> wrote: .. Apprently p%i is unallocated after the
self-assignment. Is this code still standard conforming? Hi Daniel,
Interesting question! 3 different compilers
On Mon, Jul 26, 2021 at 3:17 PM Daniel C Chen via J3 <
j3 at mailman.j3-fortran.org> wrote:
..
Apprently p%i is unallocated after the self-assignment. Is this code
still standard conforming?
Hi Daniel,
Interesting question! 3 different compilers I have access to indicate
"p%i" is indeed allocated after the "self-assignment"!
I look forward to the discussion. Paragraph 1 in section 10.2.1.3
Interpretation of intrinsic assignments [p170:11-16] reads as the
assignment you show can be interpreted *as though* it were *equivalent* to:
block
type(dt) :: tmp
tmp = p
p = tmp
end block
thereby leaving "p%i" as allocated and which is what the 3 processors I
tried appeared to be doing.
Regards,
Vipul Parekh
Disclaimer
The Numerical Algorithms Group Ltd is a company registered in England and
Wales with company number 1249803. The registered office is: 30 St. Giles,
Oxford, OX1 3LE, United Kingdom. Please see our Privacy Notice for
information on how we process personal data and for details of how to stop
or limit communications from us.
This e-mail has been scanned for all viruses and malware, and may have been
automatically archived by Mimecast Ltd, an innovator in Software as a
Service (SaaS) for business.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210727/9d960250/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210727/9d960250/attachment-0001.gif>
More information about the J3
mailing list