From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by sourceware.org (Postfix) with ESMTPS id 045CF3858D1E; Thu, 10 Feb 2022 19:50:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 045CF3858D1E X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.29] ([79.251.7.21]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N17UW-1oKcdP0bko-012XYQ; Thu, 10 Feb 2022 20:50:01 +0100 Content-Type: multipart/mixed; boundary="------------p65zHksEtwKaLiuvAf0SH62F" Message-ID: <3cbaf568-84ac-8498-558f-9560fe395d66@gmx.de> Date: Thu, 10 Feb 2022 20:49:59 +0100 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: Paul Richard Thomas Cc: gcc-patches , Alessandro Fanfarillo , Andrew Benson , "fortran@gcc.gnu.org" Newsgroups: gmane.comp.gcc.fortran,gmane.comp.gcc.patches References: <9a2667e2-8055-bcac-1862-05c8ac60ce7a@gmx.de> From: Harald Anlauf In-Reply-To: X-Provags-ID: V03:K1:e0pcPdYzS2P13bi+PpVHgw/qQYlHPeaEK9LxfLh7nG910Jy8lNi VQQdRmTb0us/OUH2v9oxYbDIYn9670UUJz3t8ZNml026pRcaxonwzWUasl4y6TgJCUS34o+ 1U5+R3clax4Egf9W6Ly4wMQ5N80E6Tpt9b6AjuYzRBF+oYsN+ef/I4BV1tE7ig1trTWlftK s5dcWCKKCXSZqNPaT0pNQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:CmUG2gIEnOM=:B6BS1Mr5Y1/COSluYoFdgU xxvPhlaTE/Rtt2BkqLPSOQ6ihIdjOSVQI9auWJctiMPEBpNUFJuYQJXRGvV6myWPopCU18RQN Nrw1BCdZ8No0ZqeKTBlntgMk74lXYMJlMgOTUquNBFLxQmkfFK75dfVKwN83xGkTd/J8ITV2l CyMihrz3d8udQYjs/CN1UkPg2SDvY0wairLQGqwnmbNSufCx0g66a1IoXfbAput4QjmMHlhyw beuhfiLtPBAX1D35FwxIoUC1Vcenu58pKMZwPi00zARCQXl0v9WS64AVdnNfiGEpl91YIrjWt /GXC06OVtNZB77ko5jEs6+kmphicT/KRsSGMNRybG9PD/kq5TeIGjEBHpU2/3BItRIwKTrr04 qC/Jcr9/pFq+/74Di2NXvgiXiRSow8MgVFrXa58SOpY4oY6dkG0M6tzz1/pF1YVB5zDrSXXNb ukbnWzsxoHa2UjstVCy1FSoh2X+urXZzLiPnnvuX1sluNORJR6MRX8SLVtXO8aXB8PzduvuEJ cGHRQK4D0Qoo9sAT8PZIE8gQ3i91hE38T2mf3sAQ2nNBTN9jwD3W8F6OqBecQq9W1l7AahXws nNCpWG68uCKHqRsCVQetMxyZnGZ9+Ykp7A5PO3ZsjVsuG+EuoBSR3A01/n32vwQhTjV05bUbl qR7UUJAFaJuuof3bOWKcIqmFf+26PJFwpiD7F0icjtZ5vlvSQOSyUwYr9/SaUUkcFvBreOWmg F/i3818yiX+DtUs3dalPWsUo4Sd3s4aXVVunr3cGmRKjhdq3E5Ra/m9+0U5b2uqYw89hYaXX3 XrzIQ1CU3FTjzZSkiXhJxvdsJMUz1x5mSFgoy1xjo5GsL9J9TGnrYeqraYJIIo78wtCk3pcDl CD2IYY2vCnyAuAg9QMw95KAh7Eujr/WrMvoNINGg1Btv9Gskd/ezwHQg3u0nUcQAQF75mG9Ly hjQrbAon/5cYWEOJSsVLtJKIEWtrou+EVRSYfNHE1rjTrFg4N8VqmC5TWN1j1fVB6Imsx8vm4 15xMFyXA0C+EudtxB2AaywD5bvqHvQQARzIhMxfgpG7j5Ua4rDar4/fV6OEAKW4n8SmVO13f5 F4rWa7v0mr6mgo= X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, 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: Thu, 10 Feb 2022 19:50:06 -0000 This is a multi-part message in MIME format. --------------p65zHksEtwKaLiuvAf0SH62F Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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 patc= h > 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 compile= rs, > 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 =3D simple(21) type(simple) :: ThyType2 =3D simple(22) type(simple), allocatable :: MyType, MyType2 print *, "At start of program: ", final_count MyType =3D ThyType print *, "After 1st allocation:", final_count MyType2 =3D ThyType2 print *, "After 2nd allocation:", final_count Note that "ThyType" is now a parameter. I tested the above and found: Intel: At start of program: 0 After 1st allocation: 1 After 2nd allocation: 2 NAG 7.0: At start of program: 0 After 1st allocation: 0 After 2nd allocation: 0 Crayftn 12.0.2: At start of program: 2 After 1st allocation: 2 After 2nd allocation: 2 Nvidia 22.1: At start of program: 0 After 1st allocation: 0 After 2nd allocation: 0 So my stupid questions are: - is ThyType invoking a constructor? It is a parameter, after all. Should using it in an assignment invoke a destructor? If so why? And why does Intel then increment the final_count? - is the initialization of ThyType2 invoking a constructor? It might, if that is the implementation in the compiler, but should there be a finalization? Then ThyType2 is used in an intrinsic assignment, basically the same as the other one before. Now what is the difference? Are all compilers correct, but I do not see it? Someone please help! > Best regards > > Paul > Cheers, Harald --------------p65zHksEtwKaLiuvAf0SH62F Content-Type: text/x-fortran; charset=UTF-8; name="finalize_38b.f90" Content-Disposition: attachment; filename="finalize_38b.f90" Content-Transfer-Encoding: base64 bW9kdWxlIHRlc3Rtb2RlCiAgaW1wbGljaXQgbm9uZQoKICB0eXBlIDo6IHNpbXBsZQogICAg IGludGVnZXIgOjogaW5kCiAgY29udGFpbnMKICAgIGZpbmFsIDo6IGRlc3RydWN0b3IxCiAg ZW5kIHR5cGUgc2ltcGxlCgogIGludGVnZXIgOjogZmluYWxfY291bnQgPSAwCgpjb250YWlu cwoKICBzdWJyb3V0aW5lIGRlc3RydWN0b3IxKHNlbGYpCiAgICB0eXBlKHNpbXBsZSksIGlu dGVudChpbm91dCkgOjogc2VsZgogICAgZmluYWxfY291bnQgPSBmaW5hbF9jb3VudCArIDEK ICBlbmQgc3Vicm91dGluZSBkZXN0cnVjdG9yMQoKZW5kIG1vZHVsZSB0ZXN0bW9kZQoKcHJv Z3JhbSB0ZXN0X2ZpbmFsCiAgdXNlIHRlc3Rtb2RlCiAgaW1wbGljaXQgbm9uZQogIHR5cGUo c2ltcGxlKSwgcGFyYW1ldGVyICAgOjogVGh5VHlwZSAgID0gc2ltcGxlKDIxKQogIHR5cGUo c2ltcGxlKSAgICAgICAgICAgICAgOjogVGh5VHlwZTIgID0gc2ltcGxlKDIyKQogIHR5cGUo c2ltcGxlKSwgYWxsb2NhdGFibGUgOjogTXlUeXBlLCBNeVR5cGUyCgogIHByaW50ICosICJB dCBzdGFydCBvZiBwcm9ncmFtOiAiLCBmaW5hbF9jb3VudAoKICBNeVR5cGUgPSBUaHlUeXBl CiAgcHJpbnQgKiwgIkFmdGVyIDFzdCBhbGxvY2F0aW9uOiIsIGZpbmFsX2NvdW50CgogIE15 VHlwZTIgPSBUaHlUeXBlMgogIHByaW50ICosICJBZnRlciAybmQgYWxsb2NhdGlvbjoiLCBm aW5hbF9jb3VudAoKZW5kIHByb2dyYW0gdGVzdF9maW5hbAo= --------------p65zHksEtwKaLiuvAf0SH62F-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) by sourceware.org (Postfix) with ESMTPS id 83CAF3858C20 for ; Thu, 10 Feb 2022 19:50:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 83CAF3858C20 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1nIFS8-0007YP-6L for fortran@gcc.gnu.org; Thu, 10 Feb 2022 20:50:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: fortran@gcc.gnu.org From: Harald Anlauf Subject: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization Date: Thu, 10 Feb 2022 20:49:59 +0100 Message-ID: <3cbaf568-84ac-8498-558f-9560fe395d66@gmx.de> References: <9a2667e2-8055-bcac-1862-05c8ac60ce7a@gmx.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------p65zHksEtwKaLiuvAf0SH62F" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US In-Reply-To: Cc: gcc-patches@gcc.gnu.org X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no 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: Thu, 10 Feb 2022 19:50:07 -0000 Message-ID: <20220210194959.1Y6Isn1intpxthOmxDI4Rqhf1eNUXSL9bNZI_t4eZe0@z> This is a multi-part message in MIME format. --------------p65zHksEtwKaLiuvAf0SH62F Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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. I tested the above and found: Intel: At start of program: 0 After 1st allocation: 1 After 2nd allocation: 2 NAG 7.0: At start of program: 0 After 1st allocation: 0 After 2nd allocation: 0 Crayftn 12.0.2: At start of program: 2 After 1st allocation: 2 After 2nd allocation: 2 Nvidia 22.1: At start of program: 0 After 1st allocation: 0 After 2nd allocation: 0 So my stupid questions are: - is ThyType invoking a constructor? It is a parameter, after all. Should using it in an assignment invoke a destructor? If so why? And why does Intel then increment the final_count? - is the initialization of ThyType2 invoking a constructor? It might, if that is the implementation in the compiler, but should there be a finalization? Then ThyType2 is used in an intrinsic assignment, basically the same as the other one before. Now what is the difference? Are all compilers correct, but I do not see it? Someone please help! > Best regards > > Paul > Cheers, Harald --------------p65zHksEtwKaLiuvAf0SH62F Content-Type: text/x-fortran; charset=UTF-8; name="finalize_38b.f90" Content-Disposition: attachment; filename="finalize_38b.f90" Content-Transfer-Encoding: base64 bW9kdWxlIHRlc3Rtb2RlCiAgaW1wbGljaXQgbm9uZQoKICB0eXBlIDo6IHNpbXBsZQogICAg IGludGVnZXIgOjogaW5kCiAgY29udGFpbnMKICAgIGZpbmFsIDo6IGRlc3RydWN0b3IxCiAg ZW5kIHR5cGUgc2ltcGxlCgogIGludGVnZXIgOjogZmluYWxfY291bnQgPSAwCgpjb250YWlu cwoKICBzdWJyb3V0aW5lIGRlc3RydWN0b3IxKHNlbGYpCiAgICB0eXBlKHNpbXBsZSksIGlu dGVudChpbm91dCkgOjogc2VsZgogICAgZmluYWxfY291bnQgPSBmaW5hbF9jb3VudCArIDEK ICBlbmQgc3Vicm91dGluZSBkZXN0cnVjdG9yMQoKZW5kIG1vZHVsZSB0ZXN0bW9kZQoKcHJv Z3JhbSB0ZXN0X2ZpbmFsCiAgdXNlIHRlc3Rtb2RlCiAgaW1wbGljaXQgbm9uZQogIHR5cGUo c2ltcGxlKSwgcGFyYW1ldGVyICAgOjogVGh5VHlwZSAgID0gc2ltcGxlKDIxKQogIHR5cGUo c2ltcGxlKSAgICAgICAgICAgICAgOjogVGh5VHlwZTIgID0gc2ltcGxlKDIyKQogIHR5cGUo c2ltcGxlKSwgYWxsb2NhdGFibGUgOjogTXlUeXBlLCBNeVR5cGUyCgogIHByaW50ICosICJB dCBzdGFydCBvZiBwcm9ncmFtOiAiLCBmaW5hbF9jb3VudAoKICBNeVR5cGUgPSBUaHlUeXBl CiAgcHJpbnQgKiwgIkFmdGVyIDFzdCBhbGxvY2F0aW9uOiIsIGZpbmFsX2NvdW50CgogIE15 VHlwZTIgPSBUaHlUeXBlMgogIHByaW50ICosICJBZnRlciAybmQgYWxsb2NhdGlvbjoiLCBm aW5hbF9jb3VudAoKZW5kIHByb2dyYW0gdGVzdF9maW5hbAo= --------------p65zHksEtwKaLiuvAf0SH62F--