Hi Harald and Jerry, I have gone back to the start and have gone through finalizable derived type assignments with the F2018 in hand. I have had a dreadful time with direct by reference function calls and still am struggling with assignment number 6 in the attached. I would be very grateful if you would run this testcase for the other brands. As soon as I fix the 6th assignment, I will get on to class assignments. Best regards Paul On Fri, 11 Feb 2022 at 21:59, Paul Richard Thomas < paul.richard.thomas@gmail.com> wrote: > 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 >> > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein