Hi Paul, all, this is certainly better, and I am close to saying "go ahead", and "let's fix any fallout later".
I am still confused about the handling of F2008 backward compatibility, even more so after looking at the mentioned interp F08/0011. When referring to the published standard, this document really has a lot of "this does not seem to make sense." or "This makes even less sense..." It appears to be really tough on the F2008 text. At the risk of sounding stupid, but what line of interpretation do we normally follow? The published standard as-is, or rather take into account the interpretation, even if it says that the published document does not make sense? If I understood you correctly, you are trying to implement a backward compatibility, and the warning you emit refers to the pre-interp version. I haven't looked at the latest standard, but I guess you spent a lot of time on it: is there a difference between the interp version and the F2018 version? If not, wouldn't your/our life be easier if we focus on no-nonsense interpretations? Or is there a convincing reason to support the pre-interp variant? (From a practical point of view, a "F2018+ only" compliant finalization would be more than most competitors offer... :) Thanks, Harald Gesendet: Samstag, 07. Januar 2023 um 11:57 Uhr Von: "Paul Richard Thomas" <paul.richard.tho...@gmail.com> An: "Harald Anlauf" <anl...@gmx.de> Cc: "Jerry D" <jvdelis...@gmail.com>, "fortran" <fortran@gcc.gnu.org> Betreff: Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization Hi All, Please find attached a patch for trans-array.cc that does what Harald suggests; ie. finalization of array and structure constructors only occurs with -std=f2003/8. Two versions of finalize_38.f90 are attached. One which tests -std=gnu/f20018 and the other -std=f2008. Frankly, I think that this is better. Finalization of these expressions must be handled with a lot of care and was deleted by f2018 for good reasons. Above all else, the results do not represent defined entities and so it does not really make sense to finalize them. My vote is to go with this version of the patch. I am struggling a bit with a nit in finalize_45. One of the other processors appears to nullify the pointer component of the result of construct_t during finalization of the result. I can see the sense in this but do not find any requirement to do so in the standard. Given the scale of the overall patch, I am beginning to have a lot of sympathy with Thomas's suggestion that the finalization calls should be moved to the front end! I will take a quick look to see how easy this would be to implement. Regards Paul On Fri, 6 Jan 2023 at 08:34, Harald Anlauf via Fortran <fortran@gcc.gnu.org[mailto:fortran@gcc.gnu.org]> wrote:Hi Jerry, > Gesendet: Freitag, 06. Januar 2023 um 04:08 Uhr > Von: "Jerry D" <jvdelis...@gmail.com[mailto:jvdelis...@gmail.com]> > An: "Harald Anlauf" <anl...@gmx.de[mailto:anl...@gmx.de]>, "fortran" > <fortran@gcc.gnu.org[mailto:fortran@gcc.gnu.org]> > Betreff: Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish > derived-type finalization > > On 1/5/23 1:14 PM, Harald Anlauf via Fortran wrote: > > Resending as plain text, as the original version did not appear on the > > fortran list... > > > > > > Gesendet: Donnerstag, 05. Januar 2023 um 22:10 Uhr > > Von: "Harald Anlauf" <anl...@gmx.de[mailto:anl...@gmx.de]> > > An: "Paul Richard Thomas" > > <paul.richard.tho...@gmail.com[mailto:paul.richard.tho...@gmail.com]> > > Cc: "fortran@gcc.gnu.org[mailto:fortran@gcc.gnu.org]"; > > <fortran@gcc.gnu.org[mailto:fortran@gcc.gnu.org]>, "Alessandro Fanfarillo" > > <alessandro.fanfari...@gmail.com[mailto:alessandro.fanfari...@gmail.com]>, > > "Andrew Benson" > > <aben...@carnegiescience.edu[mailto:aben...@carnegiescience.edu]>, "Thomas > > Koenig" <tkoe...@gcc.gnu.org[mailto:tkoe...@gcc.gnu.org]>, "Damian Rouson" > > <damian@archaeologic.codes> > > Betreff: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish > > derived-type finalization > > > > Dear Paul, all, > > > > I had a first look at the patch and the testcases, and I really look > > forward to getting this into gfortran. > > > > A few questions surfaced when playing with it, which is why am asking for > > others to comment. > > > > Testcase finalize_38.f90 exhibits a (potential) discrepancy to my > > expections when playing with options -std=f2018 and -std=gnu (the default). > > > > What is the expected behavior of -std=gnu? My expectation is that -std=gnu > > always corresponds to the latest implemented standard (currently F2018), > > except for possibly allowing for GNU-extensions. This might imply that > > corrigenda to a standard or a newer version may lead (over time) to an > > adjustment of the behavior. Any opinions on it? Do we need to always test > > (in the testsuite) for compliance with older standards? > > > > My understanding is that -std=gnu tends to be the least restrictive and > will allow finalize_38.f90 to compile possibly with warnings. The > warnings are to allow the user to know thay are out of current > compliance, but we should not fail on code that was previously compliant > and less we specify -std=f2018 which is more restrictive. So if e.g. finalize_38.f90 compiles without warnings with -std=f2018, it should also compile without warnings with -std=gnu, right? Harald > Jerry > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
