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][stage1] Remove conditionals around free()

Hi Bernhard! On 2023-03-01T22:28:56+0100, Bernhard Reutner-Fischer via Gcc-patches wrote: > // POSIX: free(NULL) is perfectly valid > // quote: If ptr is a null pointer, no action shall occur. > @ rule1 @ > expression e; > @@ > > - if (e != NULL) > - { free(e); } > + free (e); Nice, Coccinelle

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?

Segfault when using defined assignment

I opened a PR on bugzilla for the following: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109066 The following code (compiled using current trunk), when run, causes a segfault, and valgrind complains about an invalid read. The code appears correct to me, and runs correctly (no segfault, no warn

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

BrainStorm Conference-2023

Hi Team, Hope it all goes well! I am writing to verify if you would like to obtain the list of participants/visitors? BrainStorm Conference-2023 Let us know if you are interested and we will come back with the discount cost and other deliverables. Regards, Barbara Melvin Senior Business Analy

Re: F77 indexed file support

That would have been a 360/370 IBM Mini. The 3270 was the "smart" terminal. https://imgs.search.brave.com/9CW5yhzliePl3PmZJJad0-GoiArzOyOIKkKfa0cntW8/rs:fit:640:540:1/g:ce/aHR0cHM6Ly9pLnBp/bmltZy5jb20vb3Jp/Z2luYWxzLzRlL2Nk/L2JlLzRlY2RiZTBl/YjQ0YmFlNGUzOTQ4/YjVlNDk2MWY1OWMx/LmpwZw Yes, I use data

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: F77 indexed file support

Well, that is indeed something completely different.My main frame of reference (pun not intentional) of that era was our IBM mini, I am not quite sure of the type number, 3270? It had a very specific record structure for unformatted files. Normally that was almost completely hidden, except in the j

Re: F77 indexed file support

Thank you! On 3/8/2023 1:57 AM, Bernhard Reutner-Fischer wrote: On 7 March 2023 23:18:58 CET, Roland Hughes via Fortran wrote: [ snip namelist IO ] Btw, is there a "search" utility for the archives or do I have to pull down all of the zip files, unzip into directory, and grep to look for

Re: F77 indexed file support

Hello Arjen, Thanks for your reply. You are confusing RMS Files-11 file versioning with Indexing. Sorry, this got away from me. Once I started I couldn't stop. Real computers, didn't matter who made them or their OS, all provided at least one type of indexed file. These were business class pl

Re: Request for participation in GSoC

Hello, welcome to the GCC/gfortran community. On 08.03.23 14:02, Martin Jambor wrote: On Sat, Mar 04 2023, Priyabrata Mondal via Gcc wrote: I want to participate in Google Summer of Code 2023 by contributing to the *Fortran – DO CONCURRENT* project, an implementation of loop that executes conc

Re: Request for participation in GSoC

Hello, I am happy that you found contributing to GCC interesting and doubly so that you are interested in a Fortran topic. Let me also CC the Fortran mailing list. On Sat, Mar 04 2023, Priyabrata Mondal via Gcc wrote: > Respected sir, >I am Priyabrata Mondal, an M.tech student in E

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