Re: [Patch, fortran] PR110987 and PR113885 - gimplifier ICEs and wrong results in finalization

Hi Harald, Thanks for the thumbs-up. Committed as 3c793f0361bc66d2a6bf0b3e1fb3234fc511e2a6. I will backport to 13-branch in a couple of weeks. Best regards Paul On Thu, 28 Mar 2024 at 22:27, Harald Anlauf wrote: > ...snip... > yes, this looks good here. > > ...snip... The patch looks rathe

Re: [Patch, fortran] PR110987 and PR113885 - gimplifier ICEs and wrong results in finalization

tough and invasive, so I decided that getting the right results and the correct number of finalization should be sufficient for the 14-branch release. As it happens, I had been mulling over how to do this for finalizations hidden in constructors and other contexts than assignment (eg. write stat

[Patch, fortran] PR110987 and PR113885 - gimplifier ICEs and wrong results in finalization

execution of the innermost executable construct containing the reference.", while in the present implementation, this happening just before assignment to the lhs temporary. Fixing this is going to be really tough and invasive, so I decided that getting the right results and the correct number of f

Re: [Patch, fortran] PR112459 - gfortran -w option causes derived-type finalization at creation time

fine - OK for mainline and -13 branch? Paul Fortran: Prevent unwanted finalization with -w option [PR112459] 2023-11-11 Paul Thomas gcc/fortran PR fortran/112459 * trans-array.cc (gfc_trans_array_constructor_value): Replace gfc_notification_std with explicit logical expression that selects F2003

[Patch, fortran] PR112459 - gfortran -w option causes derived-type finalization at creation time

Hi All, Evidently -w causes gfc_option.allow_std to be set to default, which allows anything and everything to happen, including these f2003/8 finalizations. The fix is trivial. Regtests fine - OK for mainline and -13 branch? Paul Fortran: Prevent unwanted finalization with -w option [PR112459

Re: [Patch, fortran] PR37336 finalization

Hi Paul, I want to get something approaching correct finalization to the distros, which implies 12-branch at present. Hopefully I can do the same with associate in a month or two's time. OK by me then. (I just wanted to be sure that we had this discussion :-) Best regards Thomas

Re: [Patch, fortran] PR37336 finalization

Hi Paul, all, On 6/3/23 15:16, Paul Richard Thomas via Gcc-patches wrote: Hi Thomas, I want to get something approaching correct finalization to the distros, which implies 12-branch at present. Hopefully I can do the same with associate in a month or two's time. IMHO it is not only di

Re: [Patch, fortran] PR37336 finalization

Hi Thomas, I want to get something approaching correct finalization to the distros, which implies 12-branch at present. Hopefully I can do the same with associate in a month or two's time. I am dithering about changing the F2003/08 part of finalization since the default is 2018 compliance.

Re: [Patch, fortran] PR37336 finalization

On Sat, Jun 03, 2023 at 07:50:19AM +0200, Thomas Koenig via Fortran wrote: > Hi Paul, > > > I propose to backport > > r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee to 12-branch very > > soon. > > Is this something that we usually do? > > While finalizati

Re: [Patch, fortran] PR37336 finalization

Hi Paul, I propose to backport r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee to 12-branch very soon. Is this something that we usually do? While finalization was basically broken before, some people still used working subsets (or subsets that were broken, and they adapted or wrote their

Re: [Patch, fortran] PR37336 finalization

Hi All, I propose to backport r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee to 12-branch very soon. Before that, I propose to remove the F2003/2008 finalization of structure and array constructors in 13- and 14-branches. I can see why it was removed from the standard in a correction to F2008

Re: finalization issue

> Cheers > > Paul > > On Wed, 3 May 2023 at 23:59, Steve Kargl via Fortran > wrote: > > > All, > > > > PR97122 shows an issue with finalization. > > It seems I attached a diff to the PR in 2020, > > which allows the code to compile. The diff > > ap

Re: finalization issue

2023 at 23:59, Steve Kargl via Fortran wrote: > All, > > PR97122 shows an issue with finalization. > It seems I attached a diff to the PR in 2020, > which allows the code to compile. The diff > applied to today's trunk still allows the > code to compile but there is now at

finalization issue

All, PR97122 shows an issue with finalization. It seems I attached a diff to the PR in 2020, which allows the code to compile. The diff applied to today's trunk still allows the code to compile but there is now at least 1 regression with finalize_8.f03. Even with my patch, I'm uncer

Re: [patch, wwwdocs] Mention finalization

Hi Thomas, Thanks for that! I think that your one-liner says it all :-) There are three PRs left open that PR37336 depends on: PR65347: Is partially fixed. The F2003/8 feature of finalization of a structure constructor within an array constructor doesn't work. I wonder if a compile o

[patch, wwwdocs] Mention finalization

0644 --- a/htdocs/gcc-13/changes.html +++ b/htdocs/gcc-13/changes.html @@ -373,7 +373,12 @@ a work-in-progress. - +Fortran + + +Finalization is now fully supported. + +

Re: [Patch, fortran] PR37336 finalization

Thank you, Richard. I am planning to commit either very late tonight, Friday night or early on Saturday morning to avoid any interference by other commits. It will take me a little while to get it done and so I want to reduce the probability of a mid-air collision. Best regards Paul >

Re: [Patch, fortran] PR37336 finalization

On Wed, 15 Mar 2023, Paul Richard Thomas wrote: > Hi All, > > I am awaiting a green light to commit this patch or not. I'd say go ahead. Richard. > Cheers > > Paul > > > On Fri, 10 Mar 2023 at 16:49, Paul Richard Thomas < > paul.richard.tho...@gmail.com> wrote: > > > Hi Thomas, > > > >

Re: [Patch, fortran] PR37336 finalization

Hi All, I am awaiting a green light to commit this patch or not. Cheers Paul On Fri, 10 Mar 2023 at 16:49, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi Thomas, > > Before answering that, I thought that I had better try the polyhedron > suite with -fwrapv and -std=legac

Re: [Patch, fortran] PR37336 finalization

Hi Thomas, Before answering that, I thought that I had better try the polyhedron suite with -fwrapv and -std=legacy together. As far as I can see, all is well and so, yes, I think that is a good idea. Cheers Paul D

Re: [Patch, fortran] PR37336 finalization

rward with this finalization patch, and commit it. More will be advanced from making this decision from not making this decision. Regards, Jerry On 3/9/23 9:30 AM, Thomas Koenig via Fortran wrote: Hi Paul, -fdefault-integer-8 does indeed fix the problem with rnflow.f90 but breaks tfft2.f90, w

Re: [Patch, fortran] PR37336 finalization

Hi Paul, -fdefault-integer-8 does indeed fix the problem with rnflow.f90 but breaks tfft2.f90, with a type mismatch at lines 36 and 44.       integer(8), parameter   :: jmul =  843314861  ! multiplicateur       integer(8), parameter   :: jadd =  453816693  ! constante additive Does the job

Re: [Patch, fortran] PR37336 finalization

On Thu, Mar 09, 2023 at 08:18:08AM +, Richard Biener wrote: > > the existing comment already explains the issue. I suppose > -fdefault-integer-8 would also work around the issue? > Please, no. -fdefault-* options should have been removed from gfortran years ago. Without a careful review, o

Re: [Patch, fortran] PR37336 finalization

Hi Richard, Good spot! -fdefault-integer-8 does indeed fix the problem with rnflow.f90 but breaks tfft2.f90, with a type mismatch at lines 36 and 44. integer(8), parameter :: jmul = 843314861 ! multiplicateur integer(8), parameter :: jadd = 453816693 ! constante additive Does

Re: [Patch, fortran] PR37336 finalization

On Thu, 9 Mar 2023, Thomas Koenig wrote: > On 08.03.23 22:35, I wrote: > > On 08.03.23 15:55, Paul Richard Thomas via Fortran wrote: > >> As noted below, rnflow.f90 hangs with the unpatched mainline at -O3 but > >> runs successfully at -O2. > > > > I can confirm that. > > > >> I presume that thi

Re: [Patch, fortran] PR37336 finalization

On Wed, 8 Mar 2023, Thomas Koenig wrote: > On 08.03.23 15:55, Paul Richard Thomas via Fortran wrote: > > As noted below, rnflow.f90 hangs with the unpatched mainline at -O3 but > > runs successfully at -O2. > > I can confirm that. > > > I presume that this is a serious regression since it involv

Re: [Patch, fortran] PR37336 finalization

On 08.03.23 22:35, I wrote: On 08.03.23 15:55, Paul Richard Thomas via Fortran wrote: As noted below, rnflow.f90 hangs with the unpatched mainline at -O3 but runs successfully at -O2. I can confirm that. I presume that this is a serious regression since it involves optimization? Which compo

Re: [Patch, fortran] PR37336 finalization

On 08.03.23 15:55, Paul Richard Thomas via Fortran wrote: As noted below, rnflow.f90 hangs with the unpatched mainline at -O3 but runs successfully at -O2. I can confirm that. I presume that this is a serious regression since it involves optimization? Which component should I post it against?

Re: [Patch, fortran] PR37336 finalization

Hi Tobias, I agree completely with all that you are saying. Declaring derived types in a module is guaranteed to produce vtables and final wrappers, so that they are available in scopes where they are used. Had we thought more about class design, we might have added the vtable to the entity, rathe

Re: [Patch, fortran] PR37336 finalization

00a0 T __ffn_data_MOD___final_ffn_data_Fe_t I do not explicitly use finalization nor do I have subprograms named __final_*. To me, this re-inforces Richard's point about not breaking existing code. I think there are two places where finalization is touched: (a) when declaring a

Re: [Patch, fortran] PR37336 finalization

I agree with Steve that the lack of finalization support in gfortran means there are not many open-source Fortran projects that rely on it. I've made extensive use of finalization: https://github.com/galacticusorg/galacticus An issue with this is that I had to work-around the missing piec

Re: [Patch, fortran] PR37336 finalization

easier to review. As to other topics in the thread, I suspect you won't find a lot of open-source Fortran project that make heavy use of finalization. This is likely due to gfortran's current lack of robust support. There, however, must some implicit finalization already occurring.

Re: [Patch, fortran] PR37336 finalization

On Wed, 8 Mar 2023, Paul Richard Thomas wrote: > Hi All, > > I ran the polyhedron testsuite with the patched gfortran-13.0.1 and 7.4(as > used in the posted Linux test). The timings are comparable except for > rnflow.f90. > > As noted below, rnflow.f90 hangs with the unpatched mainline at -O3 bu

Re: [Patch, fortran] PR37336 finalization

Hi All, I ran the polyhedron testsuite with the patched gfortran-13.0.1 and 7.4(as used in the posted Linux test). The timings are comparable except for rnflow.f90. As noted below, rnflow.f90 hangs with the unpatched mainline at -O3 but runs successfully at -O2. I presume that this is a serious

Re: [Patch, fortran] PR37336 finalization

Hi Richard, Smart pointer applications really torture finalization. That's why Andrew and Salvatore's help has been so much appreciated. I haven't run the polyhedron suite for some little while and so I just downloaded it. I ran into a significant problem with the harness. The bi

Re: [Patch, fortran] PR37336 finalization

– which SUSE has access to). In SPEC HPC, I did not see any 'final ::'. For code using finalization: In the popular non-free electronic-structure code VASP (used to calculate molecules), I see a single 'final::'. A similar less popular program is Octopus, https://gitlab.com/octop

Re: [Patch, fortran] PR37336 finalization

On Wed, 8 Mar 2023, Paul Richard Thomas wrote: > The alternative is that the patch be reviewed and committed as it is. I > have been neglecting my daytime job to get to this point and must spend > some time catching up. That works for me as well - I understand the work to be done is on the testsu

Re: [Patch, fortran] PR37336 finalization

The alternative is that the patch be reviewed and committed as it is. I have been neglecting my daytime job to get to this point and must spend some time catching up. Cheers Paul On Wed, 8 Mar 2023 at 08:05, Thomas Koenig wrote: > Hi Paul, > > > Last night, I scoped out the work required to g

Re: [Patch, fortran] PR37336 finalization

at least you can watch https://lnt.opensuse.org after-the-fact > How extensive is SPEC using finalization? My personal guess would be > that it is not used extensively, since gfortran's implementation is > pretty broken at the moment. I'd say it probably doesn't use it.

Re: [Patch, fortran] PR37336 finalization

this feature to be implemented for GCC 13. And now comes the problem - no Fortran maintanier has access to SPEC 2017, as far as I know. The curse of closed-source benchmarks... How extensive is SPEC using finalization? My personal guess would be that it is not used extensively, since gfort

Re: [Patch, fortran] PR37336 finalization

On Wed, 8 Mar 2023, Thomas Koenig wrote: > Hi Paul, > > > Last night, I scoped out the work required to get the patch ready to commit. > > Sorting out the testcases will be the main load since they have grown > > "organically". I propose to change over to one test for each paragraph of > > F2018

Re: [Patch, fortran] PR37336 finalization

Hi Paul, Last night, I scoped out the work required to get the patch ready to commit. Sorting out the testcases will be the main load since they have grown "organically". I propose to change over to one test for each paragraph of F2018 7.5.6.2/7.5.6.3 and to verify th

Re: [Patch, fortran] PR37336 finalization

e patch > > into 13-branch or I can wait until 14-branch opens. > > Personally, I think that this fixes so many bugs, and makes > the compiler so much better, that I would prefer having it > in gcc-13. Finalization was only of very limited use before, > and the risk of me

Re: [Patch, fortran] PR37336 finalization

anch or I can wait until 14-branch opens. > > Personally, I think that this fixes so many bugs, and makes > the compiler so much better, that I would prefer having it > in gcc-13. Finalization was only of very limited use before, > and the risk of meaningful regressions (short of a

Re: [Patch, fortran] PR37336 finalization

better, that I would prefer having it in gcc-13. Finalization was only of very limited use before, and the risk of meaningful regressions (short of a build failure) is therefore very low. Again, thanks a lot! Best regards Thomas

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

18 or -std=gnu to eliminate the finalization. So the question is do we follow the original f2008 text or f08/0011? (For reference, see https://j3-fortran.org/doc/year/10/10-202r1.txt which says: ``` Which is the correct approach? ANSWER: Approach 4. Constructors don't do anything that needs fi

Aw: Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

om 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"

Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

Hi Thomas, I was thinking of a function in resolve.cc, similar to generate_component_assignments that would generate the final call and, where necessary, generate a temporary and place rhs finalization after the assignment. Since this would only involve ordinary assignment and subroutine calls, I

Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

ction elimination in OMP Workshare) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50564 (forall) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69154 (matmul in where) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69742 (in associate). If you want to do the finalization of function results via a fron

Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

as'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. > > There is one drawback if you do this in the front end: There are a few > places where it is not possible to a

Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

Hi Paul, first, thanks for taking on this rather monumental task! 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

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

Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

Hi Jerry, > Gesendet: Freitag, 06. Januar 2023 um 04:08 Uhr > Von: "Jerry D" > An: "Harald Anlauf" , "fortran" > Betreff: Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish > derived-type finalization > > On 1/5/23 1:14 PM

Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

quot; , "Alessandro Fanfarillo" , "Andrew Benson" , "Thomas Koenig" , "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

Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

Benson" , "Thomas Koenig" , "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.  

Re: Finalization

was planning to retire early next year, but with the economy going > south on us I am going to hold off a bit. What a crazy world we are in! > > I thought I would drop you a note when I noticed a gfortran finalization > bug 107489. Then Steve Kargl mentioned the previous patch you had

Finalization

Hi Paul, Long time no chat.  I hope you and yours are well. I was planning to retire early next year, but with the economy going south on us I am going to hold off a bit.  What a crazy world we are in! I thought I would drop you a note when I noticed a gfortran finalization bug 107489

[OG11-committed] Fortran: Fix proc pointer as elemental arg handling (was: Fortran: Fix finalization resolution with deep copy (was: [Patch][Stage 1] Fortran/OpenMP: Support mapping of DT with allocat

3311..99c288784d6 100644 --- a/gcc/testsuite/gfortran.dg/finalize_38.f90 +++ b/gcc/testsuite/gfortran.dg/finalize_38.f90 @@ -1,4 +1,5 @@ ! { dg-do compile } +! { dg-additional-options "-Ofast" } ! ! Check finalization !

PR 105542 - [F03] Orthogonal standard-conforming type finalization tests

In case it's useful to gfortran developers, the Reference-Counter repository (https://github.com/sourceryinstitute/reference-counter) contains a test/compiler_test.f90 file that separately tests each of the scenarios in which Fortran 2018 clause 7.5.6.3 requires type finalization to occur. T

Re: [OG11-committed][stage1-patch] Fortran: Fix finalization resolution with deep copy (was: [Patch][Stage 1] Fortran/OpenMP: Support mapping of DT with allocatable components)

t München, HRB 106955 commit 492ea356ce4b9e40c417b3740cc298d6cc78e870 Author: Tobias Burnus Date: Wed Apr 27 19:44:52 2022 +0200 Fortran: Fix finalization resolution with deep copy (cont) gcc/fortran/ChangeLog: * resolve.c (gfc_resolve_finalizer

[OG11-committed][stage1-patch] Fortran: Fix finalization resolution with deep copy (was: [Patch][Stage 1] Fortran/OpenMP: Support mapping of DT with allocatable components)

c6daf2090d48bc794c6809a5d98e8d9a583346bd Author: Tobias Burnus Date: Mon Apr 25 15:12:01 2022 +0200 Fortran: Fix finalization resolution with deep copy Follow-up patch to "Fortran/OpenMP: Support mapping of DT with allocatable components" https://gcc.gnu.org/pip

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

Hi Harald and Thomas, Thank you for your contributions to understanding the interpretation by different vendors of the F2018 requirements for finalization. While it does appear to be rather chaotic, the differences are down to a small number of "features" of each compiler. Before des

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

run this testcase for the other brands. This is the output of nagfor 7.1, no idea how correct this is. Best regards Thomas At start of program: final_count =0 *** 1st assignment: No finalization because MyType

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

*** 1st assignment: No finalization because MyType unallocated. After 1st assignment(var not allocated): final_count =2(0) *** 2nd assignment: MyType(=simple(1,MyType) finalized before assignment finalize simple

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

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: >> >

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

ns" 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 th

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

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 th

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

t in an assignment invoke a destructor? If so why? > >And why does Intel then increment the final_count? > > - is the initialization of ThyType2 invoking a constructor? >It might, if that is the implementation in the compiler, but >should there be a finalization? &

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

considered to be functions; (ii) Come to a conclusion about scalarization of parent components of extended type arrays; (iii) Check and, if necessary, correct the ordering of finalization in intrinsic assignment of class arrays. (iv) Finalization is difficult to graft on to existing pre-F2003

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

parent components of extended type arrays; (iii) Check and, if necessary, correct the ordering of finalization in intrinsic assignment of class arrays. (iv) Finalization is difficult to graft on to existing pre-F2003 compilers, as witnessed by the range of implementations. I would be really grateful for

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

t; 21 is presumably the value left over from simple(21) but quite why it should happen in this order is not apparent to me. > 11, 3, 2 > I am mystified as to why the finalization of 'var' is not occurring because "1 When an intrinsic assignment statement is executed (10.2

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

(simple) :: ThyType = simple(21), ThyType2 = simple(22) ! The original PR - one finalization of 'var' before (re)allocation.   MyType = ThyType   call test(1, 0, [0,0], 0) This is an intrinsic assignment. Naively I would expect MyType to be initially unallocated. ThyType is not allocatab

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

e original PR - one finalization of 'var' before (re)allocation. MyType = ThyType call test(1, 0, [0,0], 0) This is an intrinsic assignment. Naively I would expect MyType to be initially unallocated. ThyType is not allocatable and non-pointer and cannot become undefined here a

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

specify which version of Intel you tried? > ifort (IFORT) 2021.1 Beta 20201112 > > Testcase finalize_38.f90 fails for me with ifort 2021.5.0 with: > > 131 > That's the point where the interpretation of the standard diverges. Ifort uses the scalar finalization for the par

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

shing to comply with the standard as far as possible, it is more than reasonable that the two compilers comply. On application of this patch, only exception to this is the treatment of finalization of arrays of extended types, where the Intel takes "If the entity is of extended type and the pare

[Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

This patch has been an excessively long time in coming. Please accept my apologies for that. All but two of the PR37336 dependencies are fixed, The two exceptions are PRs 59694 and 65347. The former involves lack of finalization of an unreferenced entity declared in a block, which I am sure is

[Patch, fortran] PR64290 - [F03] No finalization at deallocation of LHS

Hi All, Strictly speaking, the attached patch is branching out into a more generalised attack on PR37336(Finalization) - [F03] Finish derived-type finalization but most of it fixes PR64290. I started work on this patch almost a year ago but had to drop it due daytime work pressure and only

Re: [PATCH,FORTRAN] Fix memory leak in finalization wrappers

On Sun, 7 Nov 2021 13:32:34 +0100 Mikael Morin wrote: > > btw.. Just because it's vagely related. > > I think f8add009ce300f24b75e9c2e2cc5dd944a020c28 for > > PR fortran/88009 (ICE in find_intrinsic_vtab, at fortran/class.c:2761) > > is incomplete in that i think all the internal class helpers sh

Re: [PATCH,FORTRAN] Fix memory leak in finalization wrappers

interface. I can’t convince myself that it’s either absolutely necessary or completely useless. It's a delicate spot, yes, but i do think they are completely useless. If we do NOT need a finalization, the initializer can (and has to be AFAIU) be a null_expr and AFAICS then does not need an inte

Re: [PATCH,FORTRAN] Fix memory leak in finalization wrappers

>>> On Wed, 27 Oct 2021 23:39:43 +0200 > >>> Bernhard Reutner-Fischer wrote: > >>> > >>>> On Mon, 15 Oct 2018 10:23:06 +0200 > >>>> Bernhard Reutner-Fischer wrote: > >>>> > >>>>> If a final

Re: [PATCH,FORTRAN] Fix memory leak in finalization wrappers

: On Mon, 15 Oct 2018 10:23:06 +0200 Bernhard Reutner-Fischer wrote: If a finalization is not required we created a namespace containing formal arguments for an internal interface definition but never used any of these. So the whole sub_ns namespace was not wired up to the program and consequently

Re: [PATCH,FORTRAN] Fix memory leak in finalization wrappers

>>> /* Set up the procedure symbol.  */ That’s probably not a good idea on second thought; it’s preferable to leak memory and not generate an empty finalization procedure.

Re: [PATCH,FORTRAN] Fix memory leak in finalization wrappers

#x27;ll rebase and retest this one. > >> Ok if it passes?] > > Testing passed without any new regressions. > > Ok for trunk? > > thanks, > >> > >> On Mon, 15 Oct 2018 10:23:06 +0200 > >> Bernhard Reutner-Fischer wrote: > >>

Re: [PATCH,FORTRAN] Fix memory leak in finalization wrappers

, On Mon, 15 Oct 2018 10:23:06 +0200 Bernhard Reutner-Fischer wrote: If a finalization is not required we created a namespace containing formal arguments for an internal interface definition but never used any of these. So the whole sub_ns namespace was not wired up to the program and conseq

Re: [PATCH,FORTRAN] Fix memory leak in finalization wrappers

nhard Reutner-Fischer wrote: > > > If a finalization is not required we created a namespace containing > > formal arguments for an internal interface definition but never used > > any of these. So the whole sub_ns namespace was not wired up to the > > program and

Re: [PATCH,FORTRAN] Fix memory leak in finalization wrappers

Ping [hmz. it's been a while, I'll rebase and retest this one. Ok if it passes?] On Mon, 15 Oct 2018 10:23:06 +0200 Bernhard Reutner-Fischer wrote: > If a finalization is not required we created a namespace containing > formal arguments for an internal interface definition but