From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) by sourceware.org (Postfix) with ESMTPS id ABCFD385841B for ; Fri, 11 Feb 2022 21:59:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ABCFD385841B Received: by mail-qt1-x834.google.com with SMTP id s1so10268808qtw.9 for ; Fri, 11 Feb 2022 13:59:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cylYSMTgDGL+1XWFGvugHU9xzXFD6EAxFFL/DiC4xFE=; b=PjOX382koY0ah6L2rQj2EIiUUe9ic64UdWyjuI52nPDu8O6BgwSErBNmb4FIIRjK/i bQ0lMZwTmT9P5yrwFtyyRb3TQD+uNzQCjKajcr+wr9Ass+UNV8ztIvAcKn5VAJFtYPv4 NAG4MqnkEBj3LkDo4FQbfxwU6EyYGY9+Qs/wCRBcemxx+yOzdLgvTXhUb9BeRV+JvJ0U kXfhBR/Pz6/vK5Tko/D6tECoXaTUtgRAnLb39OUwFepqGrtdkYBdGmFqG5K+a6mqP6xO M5lh/l+FFV8hp3Xo6ZTTHM1kjWLCAqO0gyy5Or/nhhgd+bOX/QVYqoG2nHeJk6R12gLz ogHA== X-Gm-Message-State: AOAM533PUmP0FU6xCrQQAT0eiqWP2u8pdiWuyrxpaml7NbkgLRATGWsG bMhRW+xJk/d1MFACZopoNmldkyaHy6Q+6Dl+eug= X-Google-Smtp-Source: ABdhPJzStPa7lnGRcnHBJTWfC4C8NrVRh/QE/ZbERkkgoeLfOQf+v7yFLH0VHE24awZU3CCPo/Z+kjg9Lf8zAhbnlBU= X-Received: by 2002:ac8:5cc4:: with SMTP id s4mr2609507qta.405.1644616757231; Fri, 11 Feb 2022 13:59:17 -0800 (PST) MIME-Version: 1.0 References: <9a2667e2-8055-bcac-1862-05c8ac60ce7a@gmx.de> <3cbaf568-84ac-8498-558f-9560fe395d66@gmx.de> <7ab973cd-f62e-28be-36e8-4e44252a4a38@gmx.de> In-Reply-To: <7ab973cd-f62e-28be-36e8-4e44252a4a38@gmx.de> From: Paul Richard Thomas Date: Fri, 11 Feb 2022 21:59:08 +0000 Message-ID: Subject: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization To: Harald Anlauf Cc: Alessandro Fanfarillo , Andrew Benson , "fortran@gcc.gnu.org" X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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:59:20 -0000 Hi Harald and Jerry, I am reworking my way through, line by line wit F2018 in hand. Up to test with offset 70, NAG looks to be right. I introduced an assignment with a direct by ref function call, which doesn't finalise at the moment. Class entities are yet to come. I'll report back early next week. Thanks for all the help. I have (re)learned to read the standard very carefully. Best regards Paul On Fri, 11 Feb 2022, 21:08 Harald Anlauf, wrote: > 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 >