Re: [PATCH] Fortran: fix ICE with bind(c) in block data [PR104332]

2023-03-09 Thread Jerry D via Fortran
On 3/9/23 10:08 AM, Harald Anlauf via Fortran wrote: Dear all, the attached almost obvious patch fixes a NULL pointer dereference in a check of a symbol with the bind(c) attribute. Regtested on x86_64-pc-linux-gnu. OK for mainline? This PR is marked as 10/11/12/13 regression, thus it should q

Re: [Patch, fortran] PR37336 finalization

2023-03-09 Thread Jerry D via Fortran
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

[PATCH] Fortran: fix ICE with bind(c) in block data [PR104332]

2023-03-09 Thread Harald Anlauf via Fortran
Dear all, the attached almost obvious patch fixes a NULL pointer dereference in a check of a symbol with the bind(c) attribute. Regtested on x86_64-pc-linux-gnu. OK for mainline? This PR is marked as 10/11/12/13 regression, thus it should qualify for a backport. It's simple enough anyway. Tha

Re: [Patch, fortran] PR37336 finalization

2023-03-09 Thread Thomas Koenig via Fortran
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

2023-03-09 Thread Steve Kargl via Fortran
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

2023-03-09 Thread Paul Richard Thomas via Fortran
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

2023-03-09 Thread Richard Biener via Fortran
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

2023-03-09 Thread Richard Biener via Fortran
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: F77 indexed file support

2023-03-09 Thread Arjen Markus via Fortran
Right, 3270 was the terminal. Wonderful beasts :). Anyway, this reminded me of an experiment I did a couple of years ago with wrapping the BerkeleyDB library in Fortran. I never had much use for it, but it works for small enough value of "work". But this is diverting a lot from the purpose of thi