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 distros, b

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. That s

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 finalization was basically broken before, some

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

While recovering from an illness here folks I have been following all of these discussions. I think I will put in my two cents worth. From what i can see, Paul's patch breaks nothing and fixes many things. The only thing holding us back is fear we might break something. The likelihood of act

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

On 08.03.23 16:12, Steve Kargl via Fortran wrote: For one of my codes, I see % foreach i (*.o) foreach? nm $i | grep final foreach? end 0280 T __beamsm_MOD___final_beamsm_Table_t 0580 T __bsam_MOD___final_bsam_Bsa_info_t 01e0 T __bsam_MOD___final_bsam_Bsa_t 000

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 pieces of

Re: [Patch, fortran] PR37336 finalization

On Wed, Mar 08, 2023 at 07:32:55AM +, Paul Richard Thomas wrote: > > Could you please review the patch on that self same time scale? I would be > happy to have feedback one file at a time. > Yes, I'll commit time to review individual patches. Smaller patches are typically easier to review.

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 binary segfaulted b

Re: [Patch, fortran] PR37336 finalization

On 08.03.23 09:55, Thomas Koenig via Fortran wrote: And now comes the problem - no Fortran maintanier has access to SPEC 2017, as far as I know. The curse of closed-source benchmarks... We (as in Codesourcery) have access to the older SPEC Accel and the newer SPEC HPC (but not to SPEC CPU – wh

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

On Wed, 8 Mar 2023, Thomas Koenig wrote: > On 08.03.23 09:14, Richard Biener wrote: > > While Fortran is not considered release critical it would be bad to > > break say the build of SPEC CPU 2017 or Polyhedron very late in the > > cycle. I'd lean towards postponing this to early stage1 and event

Re: [Patch, fortran] PR37336 finalization

On 08.03.23 09:14, Richard Biener wrote: While Fortran is not considered release critical it would be bad to break say the build of SPEC CPU 2017 or Polyhedron very late in the cycle. I'd lean towards postponing this to early stage1 and eventually backport it for GCC 13.2 if you would like this

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

Hi Thomas and Steve, 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 them against the oth

Re: [Patch, fortran] PR37336 finalization

On Tue, Mar 07, 2023 at 03:58:32PM +0100, Thomas Koenig via Fortran wrote: > Paul, > > first of all, thank you very much indeed for the hard work you put into > this! This is a great step for gfortran. Ditto**2 > > I can hurry this along to get the patch > > into 13-branch or I can wait until 1

Re: [Patch, fortran] PR37336 finalization

Paul, first of all, thank you very much indeed for the hard work you put into this! This is a great step for gfortran. I can hurry this along to get the 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

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

ization is not exactly legacy stuff. Thanks, Harald > Gesendet: Montag, 09. Januar 2023 um 21:42 Uhr > Von: "Harald Anlauf" > An: "Paul Richard Thomas" > Cc: "Jerry D" , "fortran" > Betreff: Aw: Re: Fw: Re: [Patch, fortran] PR37336 (Fina

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

Hi Paul, What causes the ICES? There were a few PRs along this line. Usually, it is the front-end pass inserting code which is illegal Fortran, and the later stages then asserting that it doesn't happen. Here are a few examples: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50690 (function e

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

Hi Thomas, What causes the ICES? Cheers Paul On Sat, 7 Jan 2023 at 15:28, Thomas Koenig wrote: > 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 fi

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 be to imple

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

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: [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 describing my in

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

Hi Paul, 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

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

Hi Paul, Am 16.02.22 um 19:49 schrieb Paul Richard Thomas via Fortran: 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

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

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

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

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 wee

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 that NAG is correct on this

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

Hi Harald, I have taken gcc-patches out of the loop for now :-) I am really sorry to be such a bother, but before we think we should > do the same as Intel, we need to understand what Intel does and whether > that is actually correct. Or not inconsistent with the standard. > And I would really l

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

For what it is worth. On 2/10/22 11:49 AM, Harald Anlauf via Fortran wrote: Hi Paul, Am 10.02.22 um 13:25 schrieb Paul Richard Thomas via Fortran: Conclusions on ifort: (i) The agreement between gfortran, with the patch applied, and ifort is strongest of all the other brands; (ii) The disagree

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

Hi Paul, Am 10.02.22 um 13:25 schrieb Paul Richard Thomas via Fortran: Conclusions on ifort: (i) The agreement between gfortran, with the patch applied, and ifort is strongest of all the other brands; (ii) The disagreements are all down to the treatment of the parent component of arrays of exten

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

Hi Harald, I have run your modified version of finalize_38.f90, and now I see > that you can get a bloody head just from scratching too much... > > crayftn 12.0.2: > > 1, 3, 1 > It appears that Cray interpret a derived type constructor as being a function call and so "6 If a specification ex

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

Remember the days when reading very old cryptic Fortran code? Remember the fixed line lengths and cryptic variable names! I fear the Standards committee has achieved history with the Standard itself it is so difficult to understand sometimes. Cheers to Paul and Harald for digging on this. Je

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

Hi Paul, Am 08.02.22 um 12:22 schrieb Paul Richard Thomas via Fortran: Hi Harald, Thanks for giving the patch a whirl. the parent components as an array. I strongly suspect that, from reading 7.5.6.2 paragraphs 2 and 3 closely, that ifort has it right. However, this is another issue to co

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

Hi Harald, Thanks for giving the patch a whirl. > the parent components as an array. I strongly suspect that, from reading > > 7.5.6.2 paragraphs 2 and 3 closely, that ifort has it right. However, > this > > is another issue to come back to in the future. > > Could you specify which version of I

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

Hi Paul, thanks for attacking this. I haven't looked at the actual patch, only tried to check the new testcases with other compilers. Am 03.02.22 um 18:14 schrieb Paul Richard Thomas via Fortran: I have tried to interpret F2018 7.5.6.2 and 7.5.6.3 as well as possible. This is not always straig

[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 tri