Re: [patch. fortran] PR102595 ICE in var_element, at fortran/decl.c

2023-01-20 Thread Jerry D via Fortran
On 1/20/23 5:46 PM, Jerry D wrote: A PARAMETER value is not allowed in a DATA statement, similar to an EQUIVALENCE. The check for this was in gfc_assign_data_value() in data.cc which turns out to be too late when trying to assign a zero sized array. Correction, the chunk in data.cc must rema

Re: Team Collaboration Considerations

2023-01-20 Thread Jerry D via Fortran
On 1/19/23 10:21 PM, Benson Muite via Fortran wrote: On 1/19/23 22:03, NightStrike wrote: On Thu, Jan 19, 2023, 13:33 Bernhard Reutner-Fischer mailto:rep.dot@gmail.com>> wrote: On 19 January 2023 13:52:55 CET, NightStrike via Fortran mailto:fortran@gcc.gnu.org>> wrote: >Yo

[patch, gfortran.dg] Allow test to pass on mingw

2023-01-20 Thread Jerry DeLisle via Fortran
Hi all, Similar to a patch I committed a while ago for Cygwin, the attached patch allows it to pass on the mingw version of gfortran. It is trivial. Ok for trunk? Regards, Jerrydiff --git a/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90 b/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f9

[patch. fortran] PR102595 ICE in var_element, at fortran/decl.c

2023-01-20 Thread Jerry D via Fortran
A PARAMETER value is not allowed in a DATA statement, similar to an EQUIVALENCE. The check for this was in gfc_assign_data_value() in data.cc which turns out to be too late when trying to assign a zero sized array. To correct this, the check is moved to match_variable() in primary.cc where

Re: nvptx, libgfortran: Switch out of "minimal" mode

2023-01-20 Thread Thomas Koenig via Fortran
Hi Thomas, On 2023-01-20T22:04:02+0100, I wrote: We've been (t)asked to enable (portions of) GCC/Fortran I/O for nvptx offloading, which means building a normal (non-'LIBGFOR_MINIMAL') configuration of libgfortran. This is achieved by 'nvptx, libgfortran: Switch out of "minimal" mode', see at

Re: git out-of-order commit (was Re: [PATCH] Fortran: Remove unused declaration)

2023-01-20 Thread Carlos O'Donell via Fortran
On 1/19/23 23:26, Bernhard Reutner-Fischer wrote: > On 19 January 2023 20:39:08 CET, Jason Merrill wrote: >> On Sat, Nov 12, 2022 at 4:24 PM Harald Anlauf via Gcc-patches >> wrote: >>> >>> Am 12.11.22 um 22:05 schrieb Bernhard Reutner-Fischer via Gcc-patches: This function definition was rem

nvptx, libgfortran: Switch out of "minimal" mode

2023-01-20 Thread Thomas Schwinge
Hi! On 2023-01-20T22:04:02+0100, I wrote: > We've been (t)asked to enable (portions of) GCC/Fortran I/O for nvptx > offloading, which means building a normal (non-'LIBGFOR_MINIMAL') > configuration of libgfortran. This is achieved by 'nvptx, libgfortran: Switch out of "minimal" mode', see attache

nvptx, libgcc: Stub unwinding implementation

2023-01-20 Thread Thomas Schwinge
Hi! We've been (t)asked to enable (portions of) GCC/Fortran I/O for nvptx offloading, which means building a normal (non-'LIBGFOR_MINIMAL') configuration of libgfortran. One prerequisite patch, based on WIP work by Andrew Stubbs, is: "nvptx, libgcc: Stub unwinding implementation", see attached.

Clean up after newlib "nvptx: In offloading execution, map '_exit' to 'abort' [GCC PR85463]"

2023-01-20 Thread Thomas Schwinge
Hi! Re the newlib commit 05a2d7a8b3277b469e7cb121115bba398adc8559 "nvptx: In offloading execution, map '_exit' to 'abort' [GCC PR85463]" that I've just pushes to newlib main branch: On 2023-01-19T23:00:05+0100, I wrote: > This is still not properly resolving > '[nvpt

Re: [Patch] OpenMP/Fortran: Partially fix non-rect loop nests [PR107424]

2023-01-20 Thread Jakub Jelinek via Fortran
On Fri, Jan 20, 2023 at 07:00:18PM +0100, Jakub Jelinek via Gcc-patches wrote: > Though, I wonder if we shouldn't for GCC 13 just sorry_at about > steps other than constant 1/-1 (in both outer loop with var-outer referenced > in inner loop and on inner loop that references it) and for the !VAR_P ca

Re: [Patch] OpenMP/Fortran: Partially fix non-rect loop nests [PR107424]

2023-01-20 Thread Jakub Jelinek via Fortran
On Fri, Jan 20, 2023 at 06:39:04PM +0100, Jakub Jelinek via Gcc-patches wrote: > > + The issue is that for those a 'count' variable is used. */ > > +dovar_init *di; > > +unsigned ix; > > +tree t = tree_var; > > +while (TREE_CODE (t) == INDIRECT_REF) > > + t = TREE_OPERAN

Re: [Patch] OpenMP/Fortran: Partially fix non-rect loop nests [PR107424]

2023-01-20 Thread Jakub Jelinek via Fortran
On Thu, Jan 19, 2023 at 03:40:19PM +0100, Tobias Burnus wrote: > + gfc_symbol *var = code->ext.iterator->var->symtree->n.sym; > + > + gfc_se se; > + tree tree_var, a1, a2; > + a1 = integer_one_node; > + a2 = integer_zero_node; > + > + gfc_init_se (&se, NULL); > + gfc_conv_expr_lhs (&se, code

Re: git out-of-order commit (was Re: [PATCH] Fortran: Remove unused declaration)

2023-01-20 Thread Jason Merrill via Fortran
On Thu, Jan 19, 2023 at 11:26 PM Bernhard Reutner-Fischer wrote: > > On 19 January 2023 20:39:08 CET, Jason Merrill wrote: > >On Sat, Nov 12, 2022 at 4:24 PM Harald Anlauf via Gcc-patches > > wrote: > >> > >> Am 12.11.22 um 22:05 schrieb Bernhard Reutner-Fischer via Gcc-patches: > >> > This funct