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 function definition was removed years ago, remove it's prototype.
> >> >
> >> > gcc/fortran/ChangeLog:
> >> >
> >> >   * gfortran.h (gfc_check_include): Remove declaration.
> >> > ---
> >> >   gcc/fortran/gfortran.h | 1 -
> >> >   1 file changed, 1 deletion(-)
> >> > ---
> >> > Regtests cleanly, ok for trunk?
> >> >
> >> > diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
> >> > index c4deec0d5b8..ce3ad61bb52 100644
> >> > --- a/gcc/fortran/gfortran.h
> >> > +++ b/gcc/fortran/gfortran.h
> >> > @@ -3208,7 +3208,6 @@ int gfc_at_eof (void);
> >> >   int gfc_at_bol (void);
> >> >   int gfc_at_eol (void);
> >> >   void gfc_advance_line (void);
> >> > -int gfc_check_include (void);
> >> >   int gfc_define_undef_line (void);
> >> >
> >> >   int gfc_wide_is_printable (gfc_char_t);
> >>
> >> OK, thanks.
> >
> >Somehow this was applied with a CommitDate in 2021, breaking scripts
> >that assume monotonically increasing CommitDate.  Anyone know how that
> >could have happened?
>
> Sorry for that.
> I think i cherry-picked this commit to master before pushing it, not 100% 
> sure though.

You would have also needed to override the commit date with
GIT_COMMITTER_DATE.  Do you remember using that environment variable
at all?

> What shall we do now?

I don't think there's anything we can do about this commit at this
point; rewriting the git history would be a bigger disruption than
leaving it alone.

Martin, I wonder about having the hooks reject out-of-order CommitDate
in future?

Jason

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->ext.iterator->var);
> +  gfc_add_block_to_block (pblock, &se.pre);
> +  tree_var = se.expr;
> +
> +  {
> +/* FIXME: Handle non-unity iterations, cf. PR fortran/107424.

I think instead of non-unity etc. it is better to talk about
constant step 1 or -1.

> +   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_OPERAND (t, 0);
> +FOR_EACH_VEC_ELT (*inits, ix, di)
> +  {
> + tree t2 = di->var;
> + while (TREE_CODE (t2) == INDIRECT_REF)
> +   t2 = TREE_OPERAND (t2, 0);

The actual problem with non-simple loops for non-rectangular loops is
both in case it is an inner loop which uses some outer loop's iterator,
or if it is outer loop whose iterator is used, both of those cases
will not be handled properly.  The former case because instead of
having lb and ub expressions in canonicalized form var-outer * m + a
lb will be 0 (that is fine) and ub will be
(var-outer * m2 + a2 + step - var-outer * m1 - a1) / step
or so (sure, we can simplify that to
(var-outer * (m1 - m2) + (a2 + step - a1)) / step
but the division remains.  And the latter case is bad because we
need var-outer but we actually compute some artificial count iterator
and var-outer is only initialized in the body of the loop.
These sorry_at seems to handle just one of those, when the outer
loop whose var-outer is referenced is not simple, no?

I wonder if it wouldn't be cleaner and easier to simply remember for
each loop in XALLOCAVEC array whether it was simple or not and why
(from the:
  if (VAR_P (dovar))
{
  if (integer_onep (step))
simple = 1;
  else if (tree_int_cst_equal (step, integer_minus_one_node))
simple = -1;
}
  else
dovar_decl
  = gfc_trans_omp_variable (code->ext.iterator->var->symtree->n.sym,
false);
remember if it was simple (1/-1) or VAR_P !simple (then we would
if needed for non-rect sorry_at about step not being constant 1 or -1)
or if it is the !VAR_P case.
And then the non-rect sorry can be emitted for both the cases easily
(especially if you precompute the:
  if (VAR_P (dovar))
{
  if (integer_onep (step))
simple_loop[i] = 1;
  else if (tree_int_cst_equal (step, integer_minus_one_node))
simple_loop[i] = -1;
  else
simple_loop[i] = 0;
}
  else
simple_loop[i] = 2;
early) and in this function check it for both loop_n and i.

> + if (t == t2)
> +   {
> + HOST_WIDE_INT intval;
> + if (gfc_extract_hwi (code->ext.iterator->step, &intval, 0) == 0
> + && intval != 1 && intval != -1)
> +   sorry_at (gfc_get_location (&code->loc),
> + "non-rectangular loop nest with non-unit loop iteration"
> + " step for %qs", var->name);

I'd say step other than constant 1 or -1.

> +  ! Use 'i' or 'j', unite stride on 'i' or on 'j' -> 4 loops

unit ?

> +  ! Then same, execpt use nonunit stride for 'k'

except, non-unit ?

> +  ! Use 'i' or 'j', unite stride on 'i' or on 'j' -> 4 loops
> +  ! Then same, execpt use nonunit stride for 'k'

2x again
(and some more later).

Jakub

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_OPERAND (t, 0);
> > +FOR_EACH_VEC_ELT (*inits, ix, di)
> > +  {
> > +   tree t2 = di->var;
> > +   while (TREE_CODE (t2) == INDIRECT_REF)
> > + t2 = TREE_OPERAND (t2, 0);
> 
> The actual problem with non-simple loops for non-rectangular loops is
> both in case it is an inner loop which uses some outer loop's iterator,
> or if it is outer loop whose iterator is used, both of those cases
> will not be handled properly.  The former case because instead of
> having lb and ub expressions in canonicalized form var-outer * m + a
> lb will be 0 (that is fine) and ub will be
> (var-outer * m2 + a2 + step - var-outer * m1 - a1) / step
> or so (sure, we can simplify that to
> (var-outer * (m1 - m2) + (a2 + step - a1)) / step
> but the division remains.  And the latter case is bad because we
> need var-outer but we actually compute some artificial count iterator
> and var-outer is only initialized in the body of the loop.
> These sorry_at seems to handle just one of those, when the outer
> loop whose var-outer is referenced is not simple, no?

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 case
actually handle it if step 1/-1 by using simple like translation just with
an artificial iterator.
Say for:
subroutine foo (x, y, z)
  integer :: x, y, z
  !$omp do private (x)
  do x = y, z
  end do
end subroutine foo
we right now in *.original dump have:
D.4265 = *y;
D.4266 = *z;
D.4267 = (1 - D.4265) + D.4266;
#pragma omp for private(count.0) private(x)
for (count.0 = 0; count.0 < D.4267; count.0 = count.0 + 1)
  {
*x = D.4265 + NON_LVALUE_EXPR ;
L.1:;
  }
What I'd suggest is:
D.4265 = *y;
D.4266 = *z;
#pragma omp for private(x)
for (x.0 = D.4265; x.0 <= D.4266; x.0 = x.0 + 1)
  {
*x = x.0;
L.1:;
  }
or so.  This could be done independently from the non-rect stuff,
as a first change.

Jakub

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 case
> actually handle it if step 1/-1 by using simple like translation just with
> an artificial iterator.

As for the steps other than constant 1/-1, we have 5 cases:
  do i = x, y, 25
or
  do i = 12, 72, z
or
  do i = x, y, -42
or
  do i = 42, -10, z
or
  do i = x, y, z
The 1st and 3rd are with constant step, 2nd and 4th with constant lower and
upper bounds and the last one has step and at least one of the bounds
non-constant.

I wonder if in the light of e.g. PR108431 which says that
do i = -huge(i), huge(i) is invalid (well, that one would be very wrong
even from OpenMP POV because computing number of iterations definitely
overflows) and the fact that we handle step 1 and -1 the simple way
do do i = huge(i) - 10, huge(i) will not work either, I wonder if even
do i = huge(i) - 5, huge(i) - 1, 2 is undefined (similar reasoning, if
i after loop needs to be set to the huge(i) + 1 it is signed integer
overflow).  If yes, then perhaps at least the first 4 cases could be easily
handled (perhaps for GCC 13 just if clauses->non_rectangular only) as
for (i = x; i <= y; i += 25)
or
for (i = 12; i <= 72; i += z)
or
for (i = x; i >= y; i -= 42)
or
for (i = 42; i >= -10; i += z)

If those give equivalent behavior, then that would mean a sorry
only for the last case - the problem is that we then don't know at compile
time the direction.
Though perhaps even for that case we could play tricks, handle
  do i = x, y, z
as
if (z > 0)
  a = x, b = y, c = z;
else
  a = INT_MIN, b = too_lazy_to_compute_that_now, c = -z;
for (counter = a; counter <= b; counter += c)
{
  if (z > 0)
i = counter;
  else
i = counter - (unsigned) INT_MAX;
}
If that works, we'd need to figure also out how to handle that
in the non-rect cases.  But the m1 * var-outer + a1 and m2 * var-outer + a2
factors can be non-constant invariants, so again we could compute something
for them depending on if the outer or inner step was positive or negative.

Jakub

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 
> '[nvptx] "exit" in offloaded region doesn't terminate process', but is
> one step into that direction, and allows for simplifying some GCC code.

> --- a/newlib/libc/machine/nvptx/_exit.c
> +++ b/newlib/libc/machine/nvptx/_exit.c

> @@ -26,7 +27,15 @@ void __attribute__((noreturn))
>  _exit (int status)
>  {
>if (__exitval_ptr)
> -*__exitval_ptr = status;
> -  for (;;)
> -asm ("exit;" ::: "memory");
> +{
> +  *__exitval_ptr = status;
> +  for (;;)
> +   asm ("exit;" ::: "memory");
> +}
> +  else /* offloading */
> +{
> +  /* Map to 'abort'; see 
> +'[nvptx] "exit" in offloaded region doesn't terminate process'.  */
> +  abort ();
> +}
>  }

That has put "the PR85463 stuff" into the one central place, and allows
for simplifying GCC as per the attached
'Clean up after newlib "nvptx: In offloading execution, map '_exit' to 'abort' 
[GCC PR85463]"',
which I've just pushed to GCC devel/omp/gcc-12 branch in
commit 094b379f461bb4b635327cde26eabc0966159fec, and intend to push to
GCC master branch once the latter depends on updated newlib for other
(functional) reasons.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 094b379f461bb4b635327cde26eabc0966159fec Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Thu, 19 Jan 2023 20:25:45 +0100
Subject: [PATCH] Clean up after newlib "nvptx: In offloading execution, map
 '_exit' to 'abort' [GCC PR85463]"

	PR target/85463
	libgfortran/
	* runtime/minimal.c [__nvptx__] (exit): Don't override.
	libgomp/
	* config/nvptx/error.c (exit): Don't override.
	* testsuite/libgomp.oacc-fortran/error_stop-1.f: Update.
	* testsuite/libgomp.oacc-fortran/error_stop-2.f: Likewise.
	* testsuite/libgomp.oacc-fortran/error_stop-3.f: Likewise.
	* testsuite/libgomp.oacc-fortran/stop-1.f: Likewise.
	* testsuite/libgomp.oacc-fortran/stop-2.f: Likewise.
	* testsuite/libgomp.oacc-fortran/stop-3.f: Likewise.
---
 libgfortran/ChangeLog.omp   |  4 
 libgfortran/runtime/minimal.c   |  8 
 libgomp/ChangeLog.omp   |  9 +
 libgomp/config/nvptx/error.c|  7 ---
 .../testsuite/libgomp.oacc-fortran/error_stop-1.f   |  8 +---
 .../testsuite/libgomp.oacc-fortran/error_stop-2.f   |  8 +---
 .../testsuite/libgomp.oacc-fortran/error_stop-3.f   |  8 +---
 libgomp/testsuite/libgomp.oacc-fortran/stop-1.f | 13 +
 libgomp/testsuite/libgomp.oacc-fortran/stop-2.f |  6 +-
 libgomp/testsuite/libgomp.oacc-fortran/stop-3.f | 12 
 10 files changed, 50 insertions(+), 33 deletions(-)
 create mode 100644 libgfortran/ChangeLog.omp

diff --git a/libgfortran/ChangeLog.omp b/libgfortran/ChangeLog.omp
new file mode 100644
index 000..b08c264daf9
--- /dev/null
+++ b/libgfortran/ChangeLog.omp
@@ -0,0 +1,4 @@
+2023-01-20  Thomas Schwinge  
+
+	PR target/85463
+	* runtime/minimal.c [__nvptx__] (exit): Don't override.
diff --git a/libgfortran/runtime/minimal.c b/libgfortran/runtime/minimal.c
index 326ff822ca7..5af2bada2f6 100644
--- a/libgfortran/runtime/minimal.c
+++ b/libgfortran/runtime/minimal.c
@@ -31,14 +31,6 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 #endif
 
 
-#if __nvptx__
-/* Map "exit" to "abort"; see PR85463 '[nvptx] "exit" in offloaded region
-   doesn't terminate process'.  */
-# undef exit
-# define exit(status) do { (void) (status); abort (); } while (0)
-#endif
-
-
 #if __nvptx__
 /* 'printf' is all we have.  */
 # undef estr_vprintf
diff --git a/libgomp/ChangeLog.omp b/libgomp/ChangeLog.omp
index 134d450f44a..33aa4b01350 100644
--- a/libgomp/ChangeLog.omp
+++ b/libgomp/ChangeLog.omp
@@ -1,5 +1,14 @@
 2023-01-20  Thomas Schwinge  
 
+	PR target/85463
+	* config/nvptx/error.c (exit): Don't override.
+	* testsuite/libgomp.oacc-fortran/error_stop-1.f: Update.
+	* testsuite/libgomp.oacc-fortran/error_stop-2.f: Likewise.
+	* testsuite/libgomp.oacc-fortran/error_stop-3.f: Likewise.
+	* testsuite/libgomp.oacc-fortran/stop-1.f: Likewise.
+	* testsuite/libgomp.oacc-fortran/stop-2.f: Likewise.
+	* testsuite/libgomp.oacc-fortran/stop-3.f: Likewise.
+
 	* testsuite/libgomp.c/simd-math-1.c: Fix configuration, again.
 
 	* testsuite/libgomp.oacc-c-c++-common/abort-3.c: Force
diff --git a/libgomp/config/nvptx/error.c b/libgomp/config/nvptx/error.c
index ab99130ed4a..1756eaeee53 100644
--- a/libgomp/config/nvptx/error.c
+

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.  This I've just pushed to devel/omp/gcc-12 branch in
commit 26d3146736218ccfdaba4da1edf969bc190d, and would like to push
to master branch once other pending GCC patches have been accepted.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 26d3146736218ccfdaba4da1edf969bc190d Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 21 Sep 2022 18:58:34 +0200
Subject: [PATCH] nvptx, libgcc: Stub unwinding implementation

Adding stub '_Unwind_Backtrace', '_Unwind_GetIPInfo' functions is necessary
for linking libbacktrace, as a normal (non-'LIBGFOR_MINIMAL') configuration
of libgfortran wants to do, for example.

The file 'libgcc/config/nvptx/unwind-nvptx.c' is copied from
'libgcc/config/gcn/unwind-gcn.c'.

libgcc/ChangeLog:

	* config/nvptx/t-nvptx: Add unwind-nvptx.c.
	* config/nvptx/unwind-nvptx.c: New file.

Co-authored-by: Andrew Stubbs 
---
 libgcc/ChangeLog.omp   |  6 +
 libgcc/config/nvptx/t-nvptx|  3 ++-
 libgcc/config/nvptx/unwind-nvptx.c | 36 ++
 3 files changed, 44 insertions(+), 1 deletion(-)
 create mode 100644 libgcc/config/nvptx/unwind-nvptx.c

diff --git a/libgcc/ChangeLog.omp b/libgcc/ChangeLog.omp
index 2e7bf5cc029..c46f49bf5b7 100644
--- a/libgcc/ChangeLog.omp
+++ b/libgcc/ChangeLog.omp
@@ -1,3 +1,9 @@
+2023-01-20  Thomas Schwinge  
+	Andrew Stubbs  
+
+	* config/nvptx/t-nvptx: Add unwind-nvptx.c.
+	* config/nvptx/unwind-nvptx.c: New file.
+
 2023-01-20  Thomas Schwinge  
 
 	* config/nvptx/crtstuff.c ["mgomp"]
diff --git a/libgcc/config/nvptx/t-nvptx b/libgcc/config/nvptx/t-nvptx
index 9a0454c3a4d..1845a38a35e 100644
--- a/libgcc/config/nvptx/t-nvptx
+++ b/libgcc/config/nvptx/t-nvptx
@@ -1,6 +1,7 @@
 LIB2ADD=$(srcdir)/config/nvptx/reduction.c \
 	$(srcdir)/config/nvptx/mgomp.c \
-	$(srcdir)/config/nvptx/atomic.c
+	$(srcdir)/config/nvptx/atomic.c \
+	$(srcdir)/config/nvptx/unwind-nvptx.c
 
 LIB2ADDEH=
 LIB2FUNCS_EXCLUDE=
diff --git a/libgcc/config/nvptx/unwind-nvptx.c b/libgcc/config/nvptx/unwind-nvptx.c
new file mode 100644
index 000..c657b2af6f3
--- /dev/null
+++ b/libgcc/config/nvptx/unwind-nvptx.c
@@ -0,0 +1,36 @@
+/* Stub unwinding implementation.
+
+   Copyright (C) 2019-2023 Free Software Foundation, Inc.
+
+   This file is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published by the
+   Free Software Foundation; either version 3, or (at your option) any
+   later version.
+
+   This file is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   Under Section 7 of GPL version 3, you are granted additional
+   permissions described in the GCC Runtime Library Exception, version
+   3.1, as published by the Free Software Foundation.
+
+   You should have received a copy of the GNU General Public License and
+   a copy of the GCC Runtime Library Exception along with this program;
+   see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+   .  */
+
+#include "unwind.h"
+
+_Unwind_Reason_Code
+_Unwind_Backtrace(_Unwind_Trace_Fn trace, void * trace_argument)
+{
+  return 0;
+}
+
+_Unwind_Ptr
+_Unwind_GetIPInfo (struct _Unwind_Context *c, int *ip_before_insn)
+{
+  return 0;
+}
-- 
2.25.1

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 attached, again based on WIP work by Andrew Stubbs.  This I've just
pushed to devel/omp/gcc-12 branch in
commit c7734c6fbb5513b4da6306de7bc85de9b8547988, and would like to push
to master branch once other pending GCC patches have been accepted.


The OpenACC XFAILs: "[...] overflows the stack for nvptx offloading"
are unresolved at this point; see the discussion around
"Handling of large stack objects in GPU code generation -- maybe transform into 
heap allocation?",
and my "nvptx: '-mframe-malloc-threshold', '-Wframe-malloc-threshold'"
experimenting.  (The latter works to some extent, but also has other
issues that I shall detail at some later point in time.)


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From c7734c6fbb5513b4da6306de7bc85de9b8547988 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 21 Sep 2022 18:58:34 +0200
Subject: [PATCH] nvptx, libgfortran: Switch out of "minimal" mode

..., in order to enable (portions of) Fortran I/O, for example.

libgfortran/ChangeLog:

	* configure: Regenerate.
	* configure.ac: No longer set LIBGFOR_MINIMAL for nvptx.

libgomp/ChangeLog:

	* testsuite/libgomp.fortran/target-print-1.f90: Adjust.
	* testsuite/libgomp.fortran/target-print-1-nvptx.f90: Remove.
	* testsuite/libgomp.oacc-fortran/print-1.f90: Adjust.
	* testsuite/libgomp.oacc-fortran/print-1-nvptx.f90: Remove.
	* testsuite/libgomp.oacc-fortran/error_stop-2.f: Adjust.
	* testsuite/libgomp.oacc-fortran/stop-2.f: Likewise.

Co-authored-by: Andrew Stubbs 
---
 libgfortran/ChangeLog.omp   |  6 ++
 libgfortran/configure   | 17 ++---
 libgfortran/configure.ac| 17 ++---
 libgomp/ChangeLog.omp   |  7 +++
 .../libgomp.fortran/target-print-1-nvptx.f90| 11 ---
 .../libgomp.fortran/target-print-1.f90  |  3 ---
 .../libgomp.oacc-fortran/error_stop-2.f |  4 +++-
 .../libgomp.oacc-fortran/print-1-nvptx.f90  | 11 ---
 .../testsuite/libgomp.oacc-fortran/print-1.f90  |  5 ++---
 libgomp/testsuite/libgomp.oacc-fortran/stop-2.f |  4 +++-
 10 files changed, 33 insertions(+), 52 deletions(-)
 delete mode 100644 libgomp/testsuite/libgomp.fortran/target-print-1-nvptx.f90
 delete mode 100644 libgomp/testsuite/libgomp.oacc-fortran/print-1-nvptx.f90

diff --git a/libgfortran/ChangeLog.omp b/libgfortran/ChangeLog.omp
index b08c264daf9..925575e65fa 100644
--- a/libgfortran/ChangeLog.omp
+++ b/libgfortran/ChangeLog.omp
@@ -1,3 +1,9 @@
+2023-01-20  Thomas Schwinge  
+	Andrew Stubbs  
+
+	* configure: Regenerate.
+	* configure.ac: No longer set LIBGFOR_MINIMAL for nvptx.
+
 2023-01-20  Thomas Schwinge  
 
 	PR target/85463
diff --git a/libgfortran/configure b/libgfortran/configure
index ae64dca3114..3e5c931d4ad 100755
--- a/libgfortran/configure
+++ b/libgfortran/configure
@@ -6230,17 +6230,12 @@ else
 fi
 
 
-# For GPU offloading, not everything in libfortran can be supported.
-# Currently, the only target that has this problem is nvptx.  The
-# following is a (partial) list of features that are unsupportable on
-# this particular target:
-# * Constructors
-# * alloca
-# * C library support for I/O, with printf as the one notable exception
-# * C library support for other features such as signal, environment
-#   variables, time functions
-
- if test "x${target_cpu}" = xnvptx; then
+# "Minimal" mode is for targets that cannot (yet) support all features of
+# libgfortran.  It avoids the need for working constructors, alloca, and C
+# library support for I/O, signals, environment variables, time functions, etc.
+# At present there are no targets that require this mode.
+
+ if false; then
   LIBGFOR_MINIMAL_TRUE=
   LIBGFOR_MINIMAL_FALSE='#'
 else
diff --git a/libgfortran/configure.ac b/libgfortran/configure.ac
index 97cc490cb5e..e5552949cc6 100644
--- a/libgfortran/configure.ac
+++ b/libgfortran/configure.ac
@@ -222,17 +222,12 @@ AM_CONDITIONAL(LIBGFOR_USE_SYMVER, [test "x$gfortran_use_symver" != xno])
 AM_CONDITIONAL(LIBGFOR_USE_SYMVER_GNU, [test "x$gfortran_use_symver" = xgnu])
 AM_CONDITIONAL(LIBGFOR_USE_SYMVER_SUN, [test "x$gfortran_use_symver" = xsun])
 
-# For GPU offloading, not everything in libfortran can be supported.
-# Currently, the only target that has this problem is nvptx.  The
-# following is a (partial) list of features that are unsupportable on
-# this particular target:
-# * Constructors
-# * alloca
-# * C library support for

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 removed years ago, remove it's prototype.

 gcc/fortran/ChangeLog:

   * gfortran.h (gfc_check_include): Remove declaration.
 ---
   gcc/fortran/gfortran.h | 1 -
   1 file changed, 1 deletion(-)
 ---
 Regtests cleanly, ok for trunk?

 diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
 index c4deec0d5b8..ce3ad61bb52 100644
 --- a/gcc/fortran/gfortran.h
 +++ b/gcc/fortran/gfortran.h
 @@ -3208,7 +3208,6 @@ int gfc_at_eof (void);
   int gfc_at_bol (void);
   int gfc_at_eol (void);
   void gfc_advance_line (void);
 -int gfc_check_include (void);
   int gfc_define_undef_line (void);

   int gfc_wide_is_printable (gfc_char_t);
>>>
>>> OK, thanks.
>>
>> Somehow this was applied with a CommitDate in 2021, breaking scripts
>> that assume monotonically increasing CommitDate.  Anyone know how that
>> could have happened?
> 
> Sorry for that.
> I think i cherry-picked this commit to master before pushing it, not 100% 
> sure though.
> What shall we do now?

I doubt a cherry-pick did this, we cherry pick often in glibc and the
commit is added to the top of checkout and the commit date updated.

There isn't anything we can do now.

I was recently made aware that --since-as-filter= was added specifically to 
address this issue.

https://patchwork.kernel.org/project/git/patch/YlnYDgZRzDI87b/z...@vmiklos.hu/
~~~
This is similar to --since, but it will filter out not matching commits,
rather than stopping at the first not matching commit.

This is useful if you e.g. want to list the commits from the last year,
but one odd commit has a bad commit date and that would hide lots of
earlier commits in that range.

The behavior of --since is left unchanged, since it's valid to depend on
its current behavior.

Signed-off-by: Miklos Vajna 
~~~

"but one odd commit has a bad commit date" :-)

We should try to avoid commits like this because they really complicate
any date-based analysis tooling, and --since-as-filter is fairly new.

-- 
Cheers,
Carlos.

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 attached, again based on WIP work by Andrew Stubbs.  This I've just
pushed to devel/omp/gcc-12 branch in
commit c7734c6fbb5513b4da6306de7bc85de9b8547988, and would like to push
to master branch once other pending GCC patches have been accepted.


Looks good to me.

Regards

Thomas

[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  a similar check for EQUIVALENCE is already being performed.


Regression tested on x86_64-linux-gnu.  I will create a test case from 
the case presented in the PR which is trivial.  There are already two 
other tests in the test suite that exercise this check.


OK for trunk?

Regards,

Jerrydiff --git a/gcc/fortran/data.cc b/gcc/fortran/data.cc
index 443d35da9cf..d29eb12c1b1 100644
--- a/gcc/fortran/data.cc
+++ b/gcc/fortran/data.cc
@@ -244,13 +244,6 @@ gfc_assign_data_value (gfc_expr *lvalue, gfc_expr *rvalue, mpz_t index,
 		"array-element nor a scalar-structure-component";
 
   symbol = lvalue->symtree->n.sym;
-  if (symbol->attr.flavor == FL_PARAMETER)
-{
-  gfc_error ("PARAMETER %qs shall not appear in a DATA statement at %L",
-		 symbol->name, &lvalue->where);
-  return false;
-}
-
   init = symbol->value;
   last_ts = &symbol->ts;
   last_con = NULL;
diff --git a/gcc/fortran/primary.cc b/gcc/fortran/primary.cc
index 543d9cc0de4..158f039f225 100644
--- a/gcc/fortran/primary.cc
+++ b/gcc/fortran/primary.cc
@@ -4076,6 +4076,11 @@ match_variable (gfc_expr **result, int equiv_flag, int host_flag)
 	  gfc_error ("Named constant at %C in an EQUIVALENCE");
 	  return MATCH_ERROR;
 	}
+  if (gfc_in_match_data())
+	{
+	  gfc_error ("PARAMETER %qs shall not appear in a DATA statement at %C",
+		  sym->name);
+	}
   /* Otherwise this is checked for and an error given in the
 	 variable definition context checks.  */
   break;

[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.f90
index 8dd7e8fb088..04faa433435 100644
--- a/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
+++ b/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
@@ -16,9 +16,9 @@ integer :: aa(4,4)
 call test(aa)
 end
 
-! { dg-final { scan-assembler-times "\[ \t\]\[$,_0-9\]*myBindC" 1 { target { ! { hppa*-*-* s390*-*-* *-*-cygwin* amdgcn*-*-* powerpc-ibm-aix*} } } } }
+! { dg-final { scan-assembler-times "\[ \t\]\[$,_0-9\]*myBindC" 1 { target { ! { hppa*-*-* s390*-*-* *-*-cygwin* amdgcn*-*-* powerpc-ibm-aix* *-*-ming* } } } } }
 ! { dg-final { scan-assembler-times "myBindC,%r2" 1 { target { hppa*-*-* } } } }
-! { dg-final { scan-assembler-times "call\tmyBindC" 1 { target { *-*-cygwin* } } } }
+! { dg-final { scan-assembler-times "call\tmyBindC" 1 { target { *-*-cygwin* *-*-ming* } } } }
 ! { dg-final { scan-assembler-times "brasl\t%r\[0-9\]*,myBindC" 1 { target { s390*-*-* } } } }
 ! { dg-final { scan-assembler-times "bl \.myBindC" 1 { target { powerpc-ibm-aix* } } } }
 ! { dg-final { scan-assembler-times "add_u32\t\[sv\]\[0-9\]*, \[sv\]\[0-9\]*, myBindC@rel32@lo" 1 { target { amdgcn*-*-* } } } }

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:

 >You can, and people naturally do this, and I think it's great, but
 >there's usually a response from someone saying "post that to the
 >mailing list instead".

 The mailing list has a 20-30 year history with reasoning about what
 currently is in the tree. I do think it is valuable to reason about
 patches publically for others to see. And I'm aware that this might
 not be regarded fancy nowadays by everyone.

 But that does not mean that using other means to collaborate should
 not be used by some. Be it comp.lang.fortran, a webchat.oftc, or
 other means, that's all fine of course.

 patches currently are handled differently, but I don't think that is
 a problem isn't it.
 Just post final patches to the list as long as that is regarded the
 way to do final review and document approval.

 cheers,


The problem is that patch tracking is unsustainable. You could go the
other way and have a patch tracker automatically echo messages to the
mailing list.


Review is done voluntarily and by email.  The process has flexibility to
increase productivity but it may make it harder to get involved.  Email
threads and metadata make it possible to track patches. It is expected,
but not enforced, that posts to the mailing list follow convention.
Until a comment on a patch is posted, it is unclear if it will be
reviewed.  Build results are tracked separately and builds done when
needed.  An  open review process is good. Do all patches get timely
reviews?  Can this process be improved?

An analysis of a developer community:
https://carlschwan.eu/2021/04/29/health-of-the-kde-community/

Some tools:
https://chaoss.github.io/grimoirelab/
https://framagit.org/ervin/ComDaAn
https://github.com/gotec/git2net

Will try some of these to analyze GCC, though something new maybe needed
since the workflow is quite different.


What I am envisioning as a workflow is to retain posting to the gfortran 
list for approvals to commit. At this stage patches are refined and 
tested already by the developer and therefore have the most value for 
the public and people wanting to learn.


Mattermost would be used for internal discussions and collaboration. 
People can post questions and examples back and forth quickly by phone, 
or web browser or desktop app interfaces. This can be done in real-time 
much better than email. Email certainly is a necessary component as a 
formal review process.


Regarding patches and such. Mattermost supports "boards" which are 
actually modeled after Kanban, a very well established methodolgy. See 
https://en.wikipedia.org/wiki/Kanban.


It allows one to see at a glance where things are at.  Individuals can 
chat with each other privately and we can also set up specific channels.


For example, I have set up for the gfortran workspace the following 
channels:


Finalization
Gfortran Development
Gfortran Front End
Gfortran Help
Gtk-Fortran Development
Gtk-Fortran Help
Native Gfortran Coarrays
Town Square - for anythin

There is nothing sacred about these, they are simply things I thought of 
during initial setup. Thes can evolve as developers determine and learn 
this tool. The point is, the channels are focus points.


I have a board where I am tracking bugs we know have patches submitted 
in bugzilla that need to get tested and committed.  So, this tool does 
not replace bugzilla either. It is a tool for us to visualize where we 
are, Work In Process.


We can create a board to track patches if we choose. In a sense, I am 
doing that already.


By the way, anyone who wishes to get on the team, send me an email. We 
will keep evolving this tool as we go.


Cheers,

Jerry

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 remain for one test case. I 
spotted this after rerunning check-fortran for several variations.


Regards,

Jerry