[J3] [EXTERNAL] Re: Self-assignment of allocatable component

[Clune, Thomas L. (GSFC-6101)]

Ah,  but by the same measure, are Fortran’s pointers “less expensive” than C pointers?     Maybe allowing for a normalization factor based on the relative size of the 2 communities.

From: J3 <j3-bounces at mailman.j3-fortran.org> on behalf of j3 <j3 at mailman.j3-fortran.org>
Reply-To: j3 <j3 at mailman.j3-fortran.org>
Date: Wednesday, July 28, 2021 at 11:44 PM
To: j3 <j3 at mailman.j3-fortran.org>
Cc: Damian Rouson <damian at sourceryinstitute.org>
Subject: [EXTERNAL] Re: [J3] Self-assignment of allocatable component

As one measure of the cost and complexity associated with a feature, someday I would love to see a count or a percentage of the of the emails on this list in response to a question roughly equal to “Is this code standard-conforming?” for code that involves a pointer.  By the suggested measure, I nominate pointers for the single most expensive feature in the history of Fortran.

Damian

Sent from my iPhone


On Jul 28, 2021, at 06:55, Vipul Parekh via J3 <j3 at mailman.j3-fortran.org> wrote:

On Wed, Jul 28, 2021 at 9:01 AM Daniel C Chen via J3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>> wrote:

Thanks Malcolm and all for the clarification.
..

From: "Malcolm Cohen via J3" <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>
To: "'General J3 interest list'" <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>..
Hi Daniel,

Yes, you are quite right, so in that case, X=X would involve at least
1.      Capturing the value of X%I,
2.      Finalising X%I,
3.      Restoring the value of X%I. ..

 Hi Daniel and Malcolm,

Interesting discussion.  If I understood the clarification thus far correctly, the following program seems to me to conform - would you agree?

 module m
   type :: t
      character(len=10) :: objname = ""
      integer :: dat = 0
   contains
      final :: finalize_t
   end type
   type, extends(t) :: u
   end type
contains
   impure elemental subroutine finalize_t( this )
      type(t), intent(inout) :: this
      print *, "t::finalize_t invoked for ", this%objname
   end subroutine
end module
module n
   use m
   type :: v
      class(t), allocatable :: i
   end type
contains
   subroutine sub()
      type(v) :: x, y
      allocate( t :: x%i ) ; x%i%objname = "x%i" ; x%i%dat = 42
      allocate( u :: y%i ) ; y%i%objname = "y%i"
      if ( allocated(y%i) ) then
         print *, "Initially, y%i%dat = ", y%i%dat, "; expected is 0"
      end if
      y = x ; y%i%objname = "y%i"
      if ( allocated(y%i) ) then
         print *, "y%i%dat = ", y%i%dat, "; expected is 42"
      end if
   end subroutine
end module
   use n
   call sub()
end

And the program output per the standard might be as follows - note the order of the last 2 lines in the output can be ignored:
 Initially, y%i%dat =            0 ; expected is 0
 t::finalize_t invoked for y%i
 y%i%dat =           42 ; expected is 42
 t::finalize_t invoked for y%i
 t::finalize_t invoked for x%i

However only one out of several processors I tried gave the above output.  There is variance among the rest when it comes to output from the (impure) finalizer.  Is the expected output I list above conformant, or is that the other processors are yet to conform to the standard when it comes to finalization?

Daniel, is it possible for you to check the IBM processor with this example and provide your feedback and comments?

Thanks,
Vipul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210729/641a254f/attachment.htm>