[J3] Self-assignment of allocatable component

Tue Jul 27 00:26:26 UTC 2021

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

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/20210726/0b27fd06/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/20210726/0b27fd06/attachment-0001.gif>