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 61BA2385801A for ; Fri, 11 Feb 2022 21:08:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 61BA2385801A Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1nId9H-0001up-OR for fortran@gcc.gnu.org; Fri, 11 Feb 2022 22:08:11 +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: Fri, 11 Feb 2022 22:08:05 +0100 Message-ID: <7ab973cd-f62e-28be-36e8-4e44252a4a38@gmx.de> References: <9a2667e2-8055-bcac-1862-05c8ac60ce7a@gmx.de> <3cbaf568-84ac-8498-558f-9560fe395d66@gmx.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------lCFrgGZEM5jZFLtwN5Ogxz0D" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Cc: Alessandro Fanfarillo , Andrew Benson , "fortran@gcc.gnu.org" Content-Language: en-US In-Reply-To: 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: Fri, 11 Feb 2022 21:08:16 -0000 Message-ID: <20220211210805.IDwYmDfKARHKRtA2YRMTOszD8ZRz3vkzg2d723S-eDk@z> This is a multi-part message in MIME format. --------------lCFrgGZEM5jZFLtwN5Ogxz0D Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Paul, Am 11.02.22 um 10:08 schrieb Paul Richard Thomas via Fortran: > Your "stupid questions" are not at all stupid. The finalization of > 'variable' that occurs in your testcase demonstrates that the finalization > with my patch is occurring at the wrong time. I now see that NAG is correct > on this. > > Please press on with the questions! Jerry's suggestion to add lots of prints turned out to be really enlightening with regard to observable behavior. I rewrote the testcase again and placed the interesting stuff into a subroutine. This way one can distinguish what actually happens during program start, entering and leaving a subroutine. I encountered the least surprises (= none) with NAG 7.0 here. For reference this is the output: At start of program : 0 Enter sub : 0 After 1st allocation: 0 After 2nd allocation: 0 Checking MyType% ind: 21 Checking MyType2%ind: 22 Deallocate MyType : 0 # Leave desctructor1: 1 21 * MyType deallocated: 1 (kept MyType2 for automatic deallocation on return from sub) Leave sub : 1 # Leave desctructor1: 2 22 After sub : 2 To make it short: the destructor is called only when deallocation occurs, either explicitly or automatically. Intel 2021.5.0: At start of program : 0 Enter sub : 0 # Leave desctructor1: 1 0 After 1st allocation: 1 # Leave desctructor1: 2 0 After 2nd allocation: 2 Checking MyType% ind: 21 Checking MyType2%ind: 22 Deallocate MyType : 2 # Leave desctructor1: 3 21 * MyType deallocated: 3 (kept MyType2 for automatic deallocation on return from sub) Leave sub : 3 # Leave desctructor1: 4 21 # Leave desctructor1: 5 22 # Leave desctructor1: 6 22 After sub : 6 So after entering the subroutine, the destructor is called twice, but for unknown reasons element ind, which I had expected to be either default-initialized to -1, or explicitly to 21 or 22, is 0. The places where this happens seem to be the assignments of MyType and MyType2. Furthermore, variable MyType is finalized on return from sub, although it is already deallocated, and MyType2 appears to get finalized twice automatically. I have no idea how this can get justified... Crayftn 12.0.2: in order to make the output easier to understand, I chose to reset final_count twice. This will become clear soon. # Leave desctructor1: 1, 20 At start of program : 1 +++ Resetting final_count for Cray Fortran : Version 12.0.2 # Leave desctructor1: 1, 21 # Leave desctructor1: 2, 22 Enter sub : 2 +++ Resetting final_count for Cray Fortran : Version 12.0.2 After 1st allocation: 0 After 2nd allocation: 0 Checking MyType% ind: -21 Checking MyType2%ind: 22 Deallocate MyType : 0 # Leave desctructor1: 1, -21 * MyType deallocated: 1 (kept MyType2 for automatic deallocation on return from sub) Leave sub : 1 # Leave desctructor1: 2, 22 After sub : 2 So it appears that Cray is calling the destructor for each declaration where a constructor is involved, or the like. Even if this is a parameter declaration, like in the main. Resetting the counter for the first time. On entering sub, I see now two finalizations before the first print. Resetting the counter for the second time. But then the assignments do not invoke finalization, where Intel did. So this part appears more like NAG, but... ... something is strange here: component ind is wrong after the first assignment. Looks clearly like a really bad bug. Explicit and automatic deallocation seems fine. Nvidia 22.2: At start of program : 0 Enter sub : 0 After 1st allocation: 0 After 2nd allocation: 0 Checking MyType% ind: 21 Checking MyType2%ind: 22 Deallocate MyType : 0 # Leave desctructor1: 1 21 * MyType deallocated: 1 (kept MyType2 for automatic deallocation on return from sub) Leave sub : 1 # Leave desctructor1: 2 1590094384 # Leave desctructor1: 3 22 After sub : 3 OK, that is really odd. Although valgrind does not report invalid accesses, there is something really fishy here. I have not investigated further. Nvidia is out for now. One of the lessons learned is that it might be hard to write a portable testcase that works for all compilers that rightfully(?) can claim to implement finalization correctly... And I have only scratched the surface so far. Paul: do you think you can enhance your much more comprehensive testcase to ease debugging further? Cheers, Harald --------------lCFrgGZEM5jZFLtwN5Ogxz0D Content-Type: text/x-fortran; charset=UTF-8; name="finalize_38b.f90" Content-Disposition: attachment; filename="finalize_38b.f90" Content-Transfer-Encoding: base64 bW9kdWxlIHRlc3Rtb2RlCiAgaW1wbGljaXQgbm9uZQoKICB0eXBlIDo6IHNpbXBsZQogICAg IGludGVnZXIgOjogaW5kID0gLTEKICBjb250YWlucwogICAgZmluYWwgOjogZGVzdHJ1Y3Rv cjEKICBlbmQgdHlwZSBzaW1wbGUKCiAgaW50ZWdlciA6OiBmaW5hbF9jb3VudCA9IDAKCmNv bnRhaW5zCgogIHN1YnJvdXRpbmUgZGVzdHJ1Y3RvcjEoc2VsZikKICAgIHR5cGUoc2ltcGxl KSwgaW50ZW50KGlub3V0KSA6OiBzZWxmCiAgICBmaW5hbF9jb3VudCA9IGZpbmFsX2NvdW50 ICsgMQogICAgcHJpbnQgKiwgIiMgTGVhdmUgZGVzY3RydWN0b3IxOiIsIGZpbmFsX2NvdW50 LCBzZWxmJSBpbmQKICAgIHNlbGYlIGluZCA9IC0gc2VsZiUgaW5kCiAgZW5kIHN1YnJvdXRp bmUgZGVzdHJ1Y3RvcjEKCmVuZCBtb2R1bGUgdGVzdG1vZGUKCnByb2dyYW0gdGVzdF9maW5h bAogIHVzZSwgaW50cmluc2ljIDo6IGlzb19mb3J0cmFuX2VudgogIHVzZSB0ZXN0bW9kZQog IGltcGxpY2l0IG5vbmUKICB0eXBlKHNpbXBsZSksIHBhcmFtZXRlciA6OiBUaHlUeXBlX3Bh cmFtID0gc2ltcGxlKDIwKQogIGNoYXJhY3Rlcig4MCkgOjogY29tcGlsZXIKICBjb21waWxl ciA9IGNvbXBpbGVyX3ZlcnNpb24gKCkKICBwcmludCAqCiAgcHJpbnQgKiwgIkF0IHN0YXJ0 IG9mIHByb2dyYW0gOiIsIGZpbmFsX2NvdW50CiAgY2FsbCByZXNldCAoKQogIHByaW50ICoK ICBjYWxsIHN1YiAoKQogIHByaW50ICoKICBwcmludCAqLCAiQWZ0ZXIgc3ViICAgICAgICAg ICA6IiwgZmluYWxfY291bnQKY29udGFpbnMKICBzdWJyb3V0aW5lIHN1YiAoKQogICAgdHlw ZShzaW1wbGUpLCBwYXJhbWV0ZXIgICA6OiBUaHlUeXBlICAgPSBzaW1wbGUoMjEpCiAgICB0 eXBlKHNpbXBsZSkgICAgICAgICAgICAgIDo6IFRoeVR5cGUyICA9IHNpbXBsZSgyMikKICAg IHR5cGUoc2ltcGxlKSwgYWxsb2NhdGFibGUgOjogTXlUeXBlLCBNeVR5cGUyCgogICAgcHJp bnQgKiwgIkVudGVyIHN1YiAgICAgICAgICAgOiIsIGZpbmFsX2NvdW50CiAgICBjYWxsIHJl c2V0ICgpCgogICAgTXlUeXBlID0gVGh5VHlwZQogICAgcHJpbnQgKiwgIkFmdGVyIDFzdCBh bGxvY2F0aW9uOiIsIGZpbmFsX2NvdW50CgogICAgTXlUeXBlMiA9IFRoeVR5cGUyCiAgICBw cmludCAqLCAiQWZ0ZXIgMm5kIGFsbG9jYXRpb246IiwgZmluYWxfY291bnQKCiAgICBwcmlu dCAqLCAiQ2hlY2tpbmcgTXlUeXBlJSBpbmQ6IiwgTXlUeXBlJSBpbmQKICAgIHByaW50ICos ICJDaGVja2luZyBNeVR5cGUyJWluZDoiLCBNeVR5cGUyJSBpbmQKICAgIGlmICgubm90LiBh bGxvY2F0ZWQgKE15VHlwZSApKSBwcmludCAqLCAiTXlUeXBlPyIKICAgIGlmICgubm90LiBh bGxvY2F0ZWQgKE15VHlwZTIpKSBwcmludCAqLCAiTXlUeXBlMj8iCgogICAgcHJpbnQgKiwg IkRlYWxsb2NhdGUgTXlUeXBlICAgOiIsIGZpbmFsX2NvdW50CiAgICBkZWFsbG9jYXRlIChN eVR5cGUpCiAgICBwcmludCAqLCAiKiBNeVR5cGUgZGVhbGxvY2F0ZWQ6IiwgZmluYWxfY291 bnQKCiAgICBpZiAoYWxsb2NhdGVkIChNeVR5cGUyKSkgJgogICAgcHJpbnQgKiwgIihrZXB0 IE15VHlwZTIgZm9yIGF1dG9tYXRpYyBkZWFsbG9jYXRpb24gb24gcmV0dXJuIGZyb20gc3Vi KSIKICAgIHByaW50ICosICJMZWF2ZSBzdWIgICAgICAgICAgIDoiLCBmaW5hbF9jb3VudAoK ICBlbmQgc3Vicm91dGluZSBzdWIKICAhCiAgc3Vicm91dGluZSByZXNldCAoKQogICAgaWYg KGZpbmFsX2NvdW50ID09IDApIHJldHVybgogICAgaWYgKGNvbXBpbGVyKDE6NCkgPT0gIkNy YXkiKSB0aGVuCiAgICAgICBwcmludCAqLCAiKysrIFJlc2V0dGluZyBmaW5hbF9jb3VudCBm b3IgIiwgdHJpbSAoY29tcGlsZXIpCiAgICAgICBmaW5hbF9jb3VudCA9IDAgISByZXNldCBm b3IgY3JheWZ0biAxMi4wLjIKICAgIGVuZCBpZgogIGVuZCBzdWJyb3V0aW5lIHJlc2V0CmVu ZCBwcm9ncmFtIHRlc3RfZmluYWwK --------------lCFrgGZEM5jZFLtwN5Ogxz0D--