Re: [PATCH v2, Fortran] [PR libfortran/101317] Bind(c): Improve error checking in CFI_* functions

2021-07-26 Thread Tobias Burnus
Hi Sandra, On 25.07.21 06:11, Sandra Loosemore wrote: Congratulation – we have found a bug in the spec, which is also present in the current draft (21-007). I have now written to J3: https://mailman.j3-fortran.org/pipermail/j3/2021-July/013189.html That discussion seems to have wandered off in

Re: Add f2008 to description

2021-07-26 Thread Tobias Burnus
Hi Vivek, On 24.07.21 16:19, Vivek Rao via Fortran wrote: The gfortran page https://gcc.gnu.org/wiki/GFortran says, "Gfortran is the name of the GNU Fortran project, developing a free Fortran 95/2003/2008 compiler for GCC, the GNU Compiler Collection."  Since Fortran 2018 features are being ad

Re: [PATCH 3/3] [PR libfortran/101305] Fix ISO_Fortran_binding.h paths in gfortran testsuite

2021-07-26 Thread Tobias Burnus
Hi Sandra, On 23.07.21 22:43, Sandra Loosemore wrote: On 7/23/21 8:15 AM, Tobias Burnus wrote: On 21.07.21 12:17, Tobias Burnus wrote: On 13.07.21 23:28, Sandra Loosemore wrote: ISO_Fortran_binding.h is now generated in the libgfortran build directory where it is on the default include path.

Committed: Re: [Patch, fortran V2] PR fortran/93308/93963/94327/94331/97046 problems raised by descriptor handling

2021-07-26 Thread Tobias Burnus
I have now committed José's patch with the two nits fixed (cf. my on-top patch to which I just replied) r12-2511-g0cbf03689e3e7d9d6002b8e5d159ef3716d0404c Note: I have slightly reworded the error message compared to both the original patch and to my on-top suggestion. Reason: When calling a BIN

Re: [PATCH 3/3] [PR libfortran/101305] Fix ISO_Fortran_binding.h paths in gfortran testsuite

2021-07-26 Thread Sandra Loosemore
On 7/26/21 3:45 AM, Tobias Burnus wrote: [snip] I did say that it mostly works because of: $ find x86_64-pc-linux-gnu/ -name ISO_Fortran_binding.h x86_64-pc-linux-gnu/libgfortran/ISO_Fortran_binding.h x86_64-pc-linux-gnu/32/libgfortran/ISO_Fortran_binding.h And when looking at the -B lines, I

Re: [PATCH] PR fortrsn/101564 - ICE in resolve_allocate_deallocate, at fortran/resolve.c:8169

2021-07-26 Thread Harald Anlauf via Fortran
Hi Tobias, > > This works as expected with Intel and AOCC, but gives a > > syntax error with every gfortran tested because of match.c: > > > > alloc_opt_list: > >m = gfc_match (" stat = %v", &tmp); > > I think we can simply change that one to %e; the definable > check should ensure that a

non_recursive vs recursive procedures

2021-07-26 Thread Steve Kargl via Fortran
In the old days, before F2018, a programmer was required to explicitly declared a procedure as RECURSIVE if the programmer wanted a recursive behavior. Fast-forward to F2018, and J3 has changed the requirements and introduced a new NON_RECURSIVE prefix; and, by defaults procedures are considered