From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) by sourceware.org (Postfix) with ESMTPS id 90B8E3858D1E; Fri, 11 Feb 2022 02:15:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 90B8E3858D1E Received: by mail-pl1-x62e.google.com with SMTP id w1so3478543plb.6; Thu, 10 Feb 2022 18:15:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=7+Gy98bJn4lzzNaDq1BarSjNr/BgaMB/ItdWgbE1otM=; b=XaiGymUoE76xsozy0/R0kfxks7OU1dRjV/s4IrN0WpiSi5C0fN7BXkgsKk/kMGN5hS L/Ihb3DgRxlFv/2iORvJOsbCOE6MxFsfeEeAZ19hb/8bC7e0fwDKC5RT10mSO5k22q/X zUSdRQ9xeLM76qP14l7j2+Sp468wApE4tU2vQSQnOqPZchgOAeQaarcNoH59EzK79fS5 h9lSGUAXpeGg+ouqyH23r8+nq4T2MmtEKj2F0ox+ftV8sQ1hi4+VdYAYNQnjGwpfir8z EJkhJI6zFIvqpoZpzBtOWXFwEQH49Rw0QH28/qiuKm+CX7B2+tIseyyWXwdqzcK+Z/ch eYTQ== X-Gm-Message-State: AOAM533OD4/mqEkfjI0ZONoGrNiTdyFhjr9Tbs17UH6QY71yUqONUsjg tyioFCdmEuXzaHbUQ08khrU= X-Google-Smtp-Source: ABdhPJxv8y+VDwtZ4lFf7ZktemSodcsieiaJ/Ofw/KeP4VEac71icJIOKRQHFR53XHTFDYcyJpwAZQ== X-Received: by 2002:a17:902:a512:: with SMTP id s18mr9943567plq.51.1644545751502; Thu, 10 Feb 2022 18:15:51 -0800 (PST) Received: from [192.168.1.28] ([50.46.203.130]) by smtp.gmail.com with ESMTPSA id j8sm1515487pjc.11.2022.02.10.18.15.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Feb 2022 18:15:51 -0800 (PST) Message-ID: <2f8d72bc-01b0-f8f7-cbd2-d931c5985d8d@gmail.com> Date: Thu, 10 Feb 2022 18:15:49 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization Content-Language: en-US To: Harald Anlauf , Paul Richard Thomas Cc: Alessandro Fanfarillo , gcc-patches , Andrew Benson , "fortran@gcc.gnu.org" References: <9a2667e2-8055-bcac-1862-05c8ac60ce7a@gmx.de> <3cbaf568-84ac-8498-558f-9560fe395d66@gmx.de> From: Jerry D In-Reply-To: <3cbaf568-84ac-8498-558f-9560fe395d66@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2022 02:15:54 -0000 For what it is worth. On 2/10/22 11:49 AM, Harald Anlauf via Fortran wrote: > Hi Paul, > > Am 10.02.22 um 13:25 schrieb Paul Richard Thomas via Fortran: >> Conclusions on ifort: >> (i) The agreement between gfortran, with the patch applied, and ifort is >> strongest of all the other brands; >> (ii) The disagreements are all down to the treatment of the parent >> component of arrays of extended types: gfortran finalizes the parent >> component as an array, whereas ifort does a scalarization. I have a >> patch >> ready to do likewise. >> >> Overall conclusions: >> (i) Sort out whether or not derived type constructors are considered >> to be >> functions; >> (ii) Come to a conclusion about scalarization of parent components of >> extended type arrays; >> (iii) Check and, if necessary, correct the ordering of finalization in >> intrinsic assignment of class arrays. >> (iv) Finalization is difficult to graft on to existing pre-F2003 >> compilers, >> as witnessed by the range of implementations. >> >> I would be really grateful for thoughts on (i) and (ii). My gut >> feeling, as >> remarked in the submission, is that we should aim to be as close as >> possible, if not identical to, ifort. Happily, that is already the case. > > I am really sorry to be such a bother, but before we think we should > do the same as Intel, we need to understand what Intel does and whether > that is actually correct.  Or not inconsistent with the standard. > And I would really like to understand even the most simple, stupid case. > > I did reduce testcase finalize_38.f90 to an almost bare minimum, > see attached, and changed the main to > >   type(simple), parameter   :: ThyType   = simple(21) >   type(simple)              :: ThyType2  = simple(22) >   type(simple), allocatable :: MyType, MyType2 > >   print *, "At start of program: ", final_count > >   MyType = ThyType >   print *, "After 1st allocation:", final_count > >   MyType2 = ThyType2 >   print *, "After 2nd allocation:", final_count > > Note that "ThyType" is now a parameter. > ----- snip ---- Ignore whether Thytype is  a Parameter.  Regardless Mytype and Mytype2 are allocated upon the assignment.  Now if these are never used anywhere, it seems to me the deallocation can be done by the compiler anywhere after the last time it is used.  So it can be either after the PRINT statement before the end if the program or right after the assignment before your PRINT statements that examine the value of final_count.  I think the result is arbitrary/undefined in your reduced test case I do not have the Intel compiler yet, so I was going to suggest see what it does if your test program prints something from within MyType and MyType2 after all your current print statements at the end.  Try this variation of the main program. program test_final   use testmode   implicit none   type(simple), parameter   :: ThyType   = simple(21)   type(simple)              :: ThyType2  = simple(22)   type(simple), allocatable :: MyType, MyType2   print *, "At start of program: ", final_count   MyType = ThyType   print *, "After 1st allocation:", final_count   MyType2 = ThyType2   print *, "After 2nd allocation:", final_count   print  *, MyType%ind, MyType2%ind, final_count   deallocate(Mytype)   print  *, MyType%ind, MyType2%ind, final_count   deallocate(Mytype2)   print  *, MyType%ind, MyType2%ind, final_count end program test_final I get with trunk: $ ./a.out  At start of program:            0  After 1st allocation:            0  After 2nd allocation:           0           21         22           0            0          22           1            0          0             2 Which makes sense to me. Regards, Jerry