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"
An: "Harald Anlauf"
Cc: "Jerry D" , "fortran"
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
mailto:fortran@gcc.gnu.org]> wrote:Hi Jerry,
> Gesendet: Freitag, 06. Januar 2023 um 04:08 Uhr
> Von: "Jerry D" mailto:jvdelis...@gmail.com]>
> An: "Harald Anlauf" mailto:anl...@gmx.de]>, "fortran"
> 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" mailto:anl...@gmx.de]>
> > An: "Paul Richard Thomas"
> > mailto:paul.richard.tho...@gmail.com]>
> > Cc: "fortran@gcc.gnu.org[mailto:fortran@gcc.gnu.org]";
> > mailto:fortran@gcc.gnu.org]>, "Alessandro Fanfarillo"
> > mailto:alessandro.fanfari...@gmail.com]>,
> > "Andrew Benson"
> > mailto:aben...@carnegiescience.edu]>, "Thomas
> > Koenig" mailto:tkoe...@gcc.gnu.org]>, "Damian Rouson"
> >
> > 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.
