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 AEB263857405; Tue, 8 Feb 2022 18:30:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AEB263857405 X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.29] ([79.232.158.126]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N8GQs-1oLNVY1nwe-014FYf; Tue, 08 Feb 2022 19:30:00 +0100 Message-ID: <9a2667e2-8055-bcac-1862-05c8ac60ce7a@gmx.de> Date: Tue, 8 Feb 2022 19:29:56 +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: Alessandro Fanfarillo , gcc-patches , Andrew Benson , "fortran@gcc.gnu.org" Newsgroups: gmane.comp.gcc.fortran,gmane.comp.gcc.patches References: From: Harald Anlauf In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:8DYMgtnw1oTrDLOF0AMXIhpAlc5xk/cfylqh9Jmqw54rq8kY86h NtGWaOrwfxetGxs3okmN6STpum/otiQOCs6OFoWoN0JgcIsJC1rUKsi3Vbs/ILI9a5dBE2M LEiAkPpSPSs+9HXvO1CXWLs6+VCAXPSHtUyJ+92yTGvHLhYIqaXuDZM+2xPkPsiLtK2qCRR /PwpHuLjekZ/SilnSMdNg== X-UI-Out-Filterresults: notjunk:1;V03:K0:o9GL5M9mh4k=:xvbpxsA3uZlJdMqanVcvnH eKSTgnptydTKW9MOPDXs7nfLnzG4TTMMIkQd8mmybqzoEPrIMm0BL5iTSiNCvLTbCGqtbCa3A YG4CBtJ0UHlvW5efYCw7Kl5BvJ1In3dbmTHgqh7TJqcL62XfaiRVwzAjnoz67ImzMlxBEI8XD bBG1t7BYrVxrVv3Djp5JbcM8Wxxmc4IAzKPwH1jKOgzULzeDnK2tLCSfclvra7s2xqJ87Cjnb xZoCHJdRN1Hx5vQMQ6tYNxKBzGvU/DecjD76Ss9I5edN3VNiFJv+gHsrfvRrKF6HYwfSd7qhH h24zyQkF2go1FGd02Gwr8tBBZlFFnbZJtSxRSacZjhR+0dUQl+g9aIBiKIlsEq9ZFDShDd9Jk U9a6GRU/5bRPucO2DV8ebKnpNqQaRH9VbJ2G3c/d7v2/b4hujIBnVPZTnLKJpQzCRB9Jl90SX PkekG56Kza9U6hX2QKKINXwznIOmkOXScihKLwWyTdVjSyttthXlm4viSqmpvizj4ZcDKhh8q YzZEc0GIaWzoqcEoixYzj3tFSQqhrnNDJml2UUtbufRDhQfcd9+C6RuQlY3IfNJfrvTHxRuY7 MdI3TQnmq2nZJZ2omN0LsSZW7VoiozG921F5XdS3r7U+FlpRSazNoAOrM886PFVFZPd+ydLJH kl9LMdTBDynMgI/juONN/hyfNYGl8nAxLRU/0DxiYhDKfUqysNASjjJ2V/vKgnPOCUWIQd5Ab SbVJb9bTy1dAToXr/sCfTonFjHbS/GBYiiln4ht05+2T5AWNSpgWuuEX2Yx1RVZka/SYB+rPm ngsd66nnBzFZiSEuDdwgCsSbM9Ka6UxBCU2heQbLsblAK7GnOFWptibt8UyP9v4gr0pTq6NMD Kkclrm14Z+DZjKrj0NBZJf/cVyBZfAPjKZiNOBqw7mV62oH+12oVX7/DEJRDmzTIyPJb8AFSO sr4glDEsHsU4xdTWQUR2OZalVHblvYHXGuhNkZtkQ6NorDEGYiXHb2Dj1/sdDGzzV6h2wWNe5 rmsQqA5mCEOhODQJ6b0hbqvPnXiCATpkgtiHguDUdayT+W2UOBK76yvJkbU67rqLBg== 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: Tue, 08 Feb 2022 18:30:04 -0000 Hi Paul, Am 08.02.22 um 12:22 schrieb Paul Richard Thomas via Fortran: > Hi Harald, > > Thanks for giving the patch a whirl. > > >> the parent components as an array. I strongly suspect that, from readin= g >>> 7.5.6.2 paragraphs 2 and 3 closely, that ifort has it right. However, >> this >>> is another issue to come back to in the future. >> >> Could you specify which version of Intel you tried? >> > > ifort (IFORT) 2021.1 Beta 20201112 ok, that's good to know. >> >> Testcase finalize_38.f90 fails for me with ifort 2021.5.0 with: >> >> 131 >> >> This test also fails with crayftn 11 & 12 and nagfor 7.0, >> but in a different place. >> I have run your modified version of finalize_38.f90, and now I see that you can get a bloody head just from scratching too much... crayftn 12.0.2: 1, 3, 1 2, 21, 0 11, 3, 2 12, 21, 1 21, 4, 3 23, 21, 22 | 42, 43 31, 6, 4 41, 7, 5 51, 9, 7 61, 10, 8 71, 13, 10 101, 2, 1 102, 4, 3 111, 3, 2 121, 4, 2 122, 0, 4 123, 5, 6 | 2*0 131, 5, 2 132, 0, 4 133, 7, 8 | 2*0 141, 6, 3 151, 10, 5 161, 16, 9 171, 18, 11 175, 0., 20. | 10., 20. nagfor 7.0: 1 0 1 11 1 2 23 21 22 | 42 43 71 9 10 72 11 99 131 3 2 132 5 4 141 4 3 151 6 5 161 10 9 171 12 11 Intel 2021.5.0: 131 3 2 132 0 4 133 5 6 | 0 0 141 4 3 151 7 5 152 3 0 153 0 0 | 1 3 forrtl: severe (174): SIGSEGV, segmentation fault occurred [...] That got me reading 7.5.6.3, where is says in paragraph 1: "When an intrinsic assignment statement is executed (10.2.1.3), if the variable is not an unallocated allocatable variable, it is finalized after evaluation of expr and before the definition of the variable. ..." Looking at the beginning of the testcase code (abridged): type(simple), allocatable :: MyType, MyType2 type(simple) :: ThyType =3D simple(21), ThyType2 =3D simple(22) ! The original PR - one finalization of 'var' before (re)allocation. MyType =3D ThyType call test(1, 0, [0,0], 0) This is an intrinsic assignment. Naively I would expect MyType to be initially unallocated. ThyType is not allocatable and non-pointer and cannot become undefined here and would not play any role in finalization. I am probably too blind-sighted to see why there should be a finalization here. What am I missing? > Could you use the attached version of finalize_38.f90 with crayftn and N= AG? > All the stop statements are replaced with prints. Ifort gives: > 131 3 2 > 132 0 4 > 133 5 6 | 0 0 > 141 4 3 > 151 7 5 > 152 3 0 > 153 0 0 | 1 3 > 161 13 9 > 162 20 0 > 163 0 0 | 10 20 > 171 14 11 I think it is a good idea to have these prints in the testcase whenever there is a departure from expectations. So print&stop? Furthermore, for the sake of health of people reading the testcases later, I think it would not harm to add more explanations why we expect a certain behavior... ;-) > Best regards > > Paul Best regards, Harald 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 7D77F385AC0A for ; Tue, 8 Feb 2022 18:30:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7D77F385AC0A Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1nHVFd-0005vi-79 for fortran@gcc.gnu.org; Tue, 08 Feb 2022 19:30:05 +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: Tue, 8 Feb 2022 19:29:56 +0100 Message-ID: <9a2667e2-8055-bcac-1862-05c8ac60ce7a@gmx.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: Tue, 08 Feb 2022 18:30:07 -0000 Message-ID: <20220208182956.gn1-sWxKMmOVCapMpNSqUnKP-p3UQGcAAMvdA2pYL30@z> Hi Paul, Am 08.02.22 um 12:22 schrieb Paul Richard Thomas via Fortran: > Hi Harald, > > Thanks for giving the patch a whirl. > > >> the parent components as an array. I strongly suspect that, from reading >>> 7.5.6.2 paragraphs 2 and 3 closely, that ifort has it right. However, >> this >>> is another issue to come back to in the future. >> >> Could you specify which version of Intel you tried? >> > > ifort (IFORT) 2021.1 Beta 20201112 ok, that's good to know. >> >> Testcase finalize_38.f90 fails for me with ifort 2021.5.0 with: >> >> 131 >> >> This test also fails with crayftn 11 & 12 and nagfor 7.0, >> but in a different place. >> I have run your modified version of finalize_38.f90, and now I see that you can get a bloody head just from scratching too much... crayftn 12.0.2: 1, 3, 1 2, 21, 0 11, 3, 2 12, 21, 1 21, 4, 3 23, 21, 22 | 42, 43 31, 6, 4 41, 7, 5 51, 9, 7 61, 10, 8 71, 13, 10 101, 2, 1 102, 4, 3 111, 3, 2 121, 4, 2 122, 0, 4 123, 5, 6 | 2*0 131, 5, 2 132, 0, 4 133, 7, 8 | 2*0 141, 6, 3 151, 10, 5 161, 16, 9 171, 18, 11 175, 0., 20. | 10., 20. nagfor 7.0: 1 0 1 11 1 2 23 21 22 | 42 43 71 9 10 72 11 99 131 3 2 132 5 4 141 4 3 151 6 5 161 10 9 171 12 11 Intel 2021.5.0: 131 3 2 132 0 4 133 5 6 | 0 0 141 4 3 151 7 5 152 3 0 153 0 0 | 1 3 forrtl: severe (174): SIGSEGV, segmentation fault occurred [...] That got me reading 7.5.6.3, where is says in paragraph 1: "When an intrinsic assignment statement is executed (10.2.1.3), if the variable is not an unallocated allocatable variable, it is finalized after evaluation of expr and before the definition of the variable. ..." Looking at the beginning of the testcase code (abridged): type(simple), allocatable :: MyType, MyType2 type(simple) :: ThyType = simple(21), ThyType2 = simple(22) ! The original PR - one finalization of 'var' before (re)allocation. MyType = ThyType call test(1, 0, [0,0], 0) This is an intrinsic assignment. Naively I would expect MyType to be initially unallocated. ThyType is not allocatable and non-pointer and cannot become undefined here and would not play any role in finalization. I am probably too blind-sighted to see why there should be a finalization here. What am I missing? > Could you use the attached version of finalize_38.f90 with crayftn and NAG? > All the stop statements are replaced with prints. Ifort gives: > 131 3 2 > 132 0 4 > 133 5 6 | 0 0 > 141 4 3 > 151 7 5 > 152 3 0 > 153 0 0 | 1 3 > 161 13 9 > 162 20 0 > 163 0 0 | 10 20 > 171 14 11 I think it is a good idea to have these prints in the testcase whenever there is a departure from expectations. So print&stop? Furthermore, for the sake of health of people reading the testcases later, I think it would not harm to add more explanations why we expect a certain behavior... ;-) > Best regards > > Paul Best regards, Harald