Re: [Ping, Patch, Fortran, PR88624, v1] Fix Rejects allocatable coarray passed as a dummy argument

2024-07-22 Thread Andre Vehreschild
Hi Paul,

thanks for the review. I have added a stripped down version of the initial
submission as testcase pr88624.f90 (for compile only) and commited as:

gcc-15-2190-g913bab282d9

Thanks for the review and regards,
Andre

On Fri, 19 Jul 2024 17:16:20 +0100
Paul Richard Thomas  wrote:

> Hi Andre,
>
> The patch looks fine to me. Please add the original testcase as
> pr88624.f90, since it can be a compile only. The addition to
> coarray/dummy_1.f90 is fine as well but I think that it is good to address
> the reporter's problem directly.
>
> Thanks
>
> Paul
>
>
> On Wed, 17 Jul 2024 at 14:10, Andre Vehreschild  wrote:
>
> > Hi all,
> >
> > and another ping...
> >
> > Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
> >
> > - Andre
> >
> > On Thu, 11 Jul 2024 15:42:54 +0200
> > Andre Vehreschild  wrote:
> >
> > > Hi all,
> > >
> > > attached patch fixes using of coarrays as dummy arguments. The coarray
> > > dummy argument was not dereferenced correctly, which is fixed now.
> > >
> > > Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline.
> > >
> > > Regards,
> > >   Andre
> > > --
> > > Andre Vehreschild * Email: vehre ad gcc dot gnu dot org
> >
> >
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
> >


--
Andre Vehreschild * Email: vehre ad gmx dot de


[Fortran, Patch, PR85510, v1] Fix coarray token in associate not linking

2024-07-22 Thread Andre Vehreschild
Hi all, hi Paul,

you asked me to have a look at PR85510 (which the associate meta bug is blocked
by). I have come up with the cause. The symbol of the coarray is deemed to be
host_associated and therefore the caf_token is not created in the correct scope.
I am not familiar with host-association, so my solution may be wrong. The
essence of my patch is to ensure, that the namespace the symbol is in is not
caused by an associate command. I hope this is the way to go.

Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?

Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 5790f80089f3c4611bd50796ca53ed5437adf012 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild 
Date: Mon, 22 Jul 2024 15:31:37 +0200
Subject: [PATCH] Fortran: Fix coarray in associate not linking [PR85510]

	PR fortran/85510

gcc/fortran/ChangeLog:

	* resolve.cc (resolve_variable): Mark the variable as host
	associated only, when it is not in an associate block.
	* trans-decl.cc (generate_coarray_init): Remove incorrect unused
	flag on parameter.

gcc/testsuite/ChangeLog:

	* gfortran.dg/coarray/pr85510.f90: New test.
---
 gcc/fortran/resolve.cc| 10 ++
 gcc/fortran/trans-decl.cc |  2 +-
 gcc/testsuite/gfortran.dg/coarray/pr85510.f90 | 19 +++
 3 files changed, 26 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/coarray/pr85510.f90

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 3bf48f793d8..393864a4a03 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -6114,10 +6114,12 @@ resolve_variable (gfc_expr *e)
   /* If a symbol has been host_associated mark it.  This is used latter,
  to identify if aliasing is possible via host association.  */
   if (sym->attr.flavor == FL_VARIABLE
-	&& gfc_current_ns->parent
-	&& (gfc_current_ns->parent == sym->ns
-	  || (gfc_current_ns->parent->parent
-		&& gfc_current_ns->parent->parent == sym->ns)))
+  && (!sym->ns->code || sym->ns->code->op != EXEC_BLOCK
+	  || !sym->ns->code->ext.block.assoc)
+  && gfc_current_ns->parent
+  && (gfc_current_ns->parent == sym->ns
+	  || (gfc_current_ns->parent->parent
+	  && gfc_current_ns->parent->parent == sym->ns)))
 sym->attr.host_assoc = 1;

   if (gfc_current_ns->proc_name
diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
index 82fa2bb6134..7d23bac6843 100644
--- a/gcc/fortran/trans-decl.cc
+++ b/gcc/fortran/trans-decl.cc
@@ -5912,7 +5912,7 @@ generate_coarray_sym_init (gfc_symbol *sym)
coarrays.  */

 static void
-generate_coarray_init (gfc_namespace * ns __attribute((unused)))
+generate_coarray_init (gfc_namespace *ns)
 {
   tree fndecl, tmp, decl, save_fn_decl;

diff --git a/gcc/testsuite/gfortran.dg/coarray/pr85510.f90 b/gcc/testsuite/gfortran.dg/coarray/pr85510.f90
new file mode 100644
index 000..c6777cad6ed
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray/pr85510.f90
@@ -0,0 +1,19 @@
+!{ dg-do run }
+
+! Contributed by Damian Rouson  
+! Check that PR fortran/85510 links.
+
+module foo
+contains
+  subroutine bar()
+integer, save :: i[*] = 1
+associate(n=>1)
+  if (i[1] /= 1) stop 1
+end associate
+  end subroutine
+end module
+
+use foo
+call bar()
+end
+
--
2.45.2



[patch, libgfortran] PR105361 Incorrect end-of-file condition for derived-type I/O

2024-07-22 Thread Jerry D

Hi all,

The attached patch fixes this by avoiding looking for and avoiding the 
EOF condition in the parent READ after returning from the child IO process.


I could not think of a simple test case yet since the problem occurred 
only when redirecting the input to the test program via a pipe.  If I 
have some more time today I will try to come up with something.


OK for mainline?

Jerry

commit e6fa9d84cf126630c9ea744aabec6d7715087310 (HEAD -> master)
Author: Jerry DeLisle 
Date:   Sun Jul 21 19:19:00 2024 -0700

Fortran: Suppress wrong End Of File error with user defined IO.

libgfortran/ChangeLog:
PR libfortran/105361
* io/list_read.c (finish_list_read): Add a condition check for
a user defined derived type IO operation to avoid calling the
EOF error.
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index 5bbbef26c26..96b2efe854f 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -2431,7 +2431,8 @@ finish_list_read (st_parameter_dt *dtp)
   /* Set the next_char and push_char worker functions.  */
   set_workers (dtp);
 
-  if (likely (dtp->u.p.child_saved_iostat == LIBERROR_OK))
+  if (likely (dtp->u.p.child_saved_iostat == LIBERROR_OK)
+ && ((dtp->common.flags & IOPARM_DT_HAS_UDTIO) == 0))
{
  c = next_char (dtp);
  if (c == EOF)


[PATCH] fortran: Support optional dummy as BACK argument of MINLOC/MAXLOC.

2024-07-22 Thread Mikael Morin
From: Mikael Morin 

Hello,

this fixes a null pointer dereference with absent optional dummy passed
as BACK argument of MINLOC/MAXLOC.

Tested for regression on x86_64-linux.
OK for master?

-- >8 --

Protect the evaluation of BACK with a check that the reference is non-null
in case the expression is an optional dummy, in the inline code generated
for MINLOC and MAXLOC.

This change contains a revert of the non-testsuite part of commit
r15-1994-ga55d24b3cf7f4d07492bb8e6fcee557175b47ea3, which factored the
evaluation of BACK out of the loop using the scalarizer.  It was a bad idea,
because delegating the argument evaluation to the scalarizer makes it
cumbersome to add a null pointer check next to the evaluation.

Instead, evaluate BACK at the beginning, before scalarization, add a check
that the argument is present if necessary, and evaluate the resulting
expression to a variable, before using the variable in the inline code.

gcc/fortran/ChangeLog:

* trans-intrinsic.cc (maybe_absent_optional_variable): New function.
(gfc_conv_intrinsic_minmaxloc): Remove BACK from scalarization and
evaluate it before.  Add a check that BACK is not null if the
expression is an optional dummy.  Save the resulting expression to a
variable.  Use the variable in the generated inline code.

gcc/testsuite/ChangeLog:

* gfortran.dg/maxloc_6.f90: New test.
* gfortran.dg/minloc_7.f90: New test.
---
 gcc/fortran/trans-intrinsic.cc |  81 +-
 gcc/testsuite/gfortran.dg/maxloc_6.f90 | 366 +
 gcc/testsuite/gfortran.dg/minloc_7.f90 | 366 +
 3 files changed, 799 insertions(+), 14 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/maxloc_6.f90
 create mode 100644 gcc/testsuite/gfortran.dg/minloc_7.f90

diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intrinsic.cc
index 180d0d7a88c..9f3c3ce47bc 100644
--- a/gcc/fortran/trans-intrinsic.cc
+++ b/gcc/fortran/trans-intrinsic.cc
@@ -5209,6 +5209,50 @@ gfc_conv_intrinsic_dot_product (gfc_se * se, gfc_expr * 
expr)
 }
 
 
+/* Tells whether the expression E is a reference to an optional variable whose
+   presence is not known at compile time.  Those are variable references 
without
+   subreference; if there is a subreference, we can assume the variable is
+   present.  We have to special case full arrays, which we represent with a 
fake
+   "full" reference, and class descriptors for which a reference to data is not
+   really a subreference.  */
+
+bool
+maybe_absent_optional_variable (gfc_expr *e)
+{
+  if (!(e && e->expr_type == EXPR_VARIABLE))
+return false;
+
+  gfc_symbol *sym = e->symtree->n.sym;
+  if (!sym->attr.optional)
+return false;
+
+  gfc_ref *ref = e->ref;
+  if (ref == nullptr)
+return true;
+
+  if (ref->type == REF_ARRAY
+  && ref->u.ar.type == AR_FULL
+  && ref->next == nullptr)
+return true;
+
+  if (!(sym->ts.type == BT_CLASS
+   && ref->type == REF_COMPONENT
+   && ref->u.c.component == CLASS_DATA (sym)))
+return false;
+
+  gfc_ref *next_ref = ref->next;
+  if (next_ref == nullptr)
+return true;
+
+  if (next_ref->type == REF_ARRAY
+  && next_ref->u.ar.type == AR_FULL
+  && next_ref->next == nullptr)
+return true;
+
+  return false;
+}
+
+
 /* Remove unneeded kind= argument from actual argument list when the
result conversion is dealt with in a different place.  */
 
@@ -5321,11 +5365,11 @@ gfc_conv_intrinsic_minmaxloc (gfc_se * se, gfc_expr * 
expr, enum tree_code op)
   tree nonempty;
   tree lab1, lab2;
   tree b_if, b_else;
+  tree back;
   gfc_loopinfo loop;
   gfc_actual_arglist *actual;
   gfc_ss *arrayss;
   gfc_ss *maskss;
-  gfc_ss *backss;
   gfc_se arrayse;
   gfc_se maskse;
   gfc_expr *arrayexpr;
@@ -5391,10 +5435,27 @@ gfc_conv_intrinsic_minmaxloc (gfc_se * se, gfc_expr * 
expr, enum tree_code op)
 && maskexpr->symtree->n.sym->attr.dummy
 && maskexpr->symtree->n.sym->attr.optional;
   backexpr = actual->next->next->expr;
-  if (backexpr)
-backss = gfc_get_scalar_ss (gfc_ss_terminator, backexpr);
+
+  gfc_init_se (&backse, NULL);
+  if (backexpr == nullptr)
+back = logical_false_node;
+  else if (maybe_absent_optional_variable (backexpr))
+{
+  gcc_assert (backexpr->expr_type == EXPR_VARIABLE);
+
+  gfc_conv_expr (&backse, backexpr);
+  tree present = gfc_conv_expr_present (backexpr->symtree->n.sym, false);
+  back = fold_build2_loc (input_location, TRUTH_ANDIF_EXPR,
+ logical_type_node, present, backse.expr);
+}
   else
-backss = nullptr;
+{
+  gfc_conv_expr (&backse, backexpr);
+  back = backse.expr;
+}
+  gfc_add_block_to_block (&se->pre, &backse.pre);
+  back = gfc_evaluate_now_loc (input_location, back, &se->pre);
+  gfc_add_block_to_block (&se->pre, &backse.post);
 
   nonempty = NULL;
   if (maskexpr && maskexpr->rank != 0)
@@ -5455,9 +5516,6 @@ gfc_conv_intrinsic_minmaxloc

Planned Fortran unsigned numbers branch

2024-07-22 Thread Thomas Koenig

Hi everybody,

now that a proposal for unsigned number inclusion in Fortran has
passed the J3 hurdle, https://j3-fortran.org/doc/year/24/24-116.txt ,
I thought I would put my working hours where my mouth is and try
my hand at a testbed implementation for gfortran.  I am still
grateful to Reinhold that he put this on the DIN list as a
suggestion.

I will use the text above as a preliminary spec.  Of course, there
is a chance that the feature may actually not make it into F2028,
or that there would be differences, but that is what experimental
work is for.

As for my motivation, I hate having to drop to C because Fortran
lacks a feature :-)

Everything will be hidden behind a flag, tentatively called
-funsigned, to allow inclusion into the compiler at a later date.

The amount of work will be substantial, but not too difficult - mostly
copying and modifying what already works for integers

Putting the work on a public branch probably works best; I will
do so in the next few days. As name, I will use fortran_unsigned,
unless somebody has a better idea.

As to when this will be finished... I don't know, it could already
be somewhat usable before being complete.  It is also work that can
be split into many relatively small parts, just implementing one
feature at a time.

Best regards

Thomas


Re: Planned Fortran unsigned numbers branch

2024-07-22 Thread Paul Richard Thomas
Hi Thomas,

Welcome back!

I was going to propose that we introduce -std=f2028 and to allow proposed
features to be run only if that option is selected; ie. not by default or
-std=gnu. gfortran.dg should have an f2028 directory as well.

I have already written and tested a patch for Reinhold Bader's proposed
assumed rank features, extended to include pointer assignment. Please see
the attached. I was so taken by his proposal because it is so intuitive and
easy to implement that I decided to pursue it in his memory. I will be
writing the standards boilerplate as well.

The likely timescale for implementation of f2028 is such that I am unlikely
to be around and so wanted to be sure that such test work as I do is
incorporated in gfortran. We have found in the past that experimental
branches are fraught with maintenance problems and tend to wither and die.

What do you think?

Regards

Paul

On Mon, 22 Jul 2024 at 22:21, Thomas Koenig  wrote:

> Hi everybody,
>
> now that a proposal for unsigned number inclusion in Fortran has
> passed the J3 hurdle, https://j3-fortran.org/doc/year/24/24-116.txt ,
> I thought I would put my working hours where my mouth is and try
> my hand at a testbed implementation for gfortran.  I am still
> grateful to Reinhold that he put this on the DIN list as a
> suggestion.
>
> I will use the text above as a preliminary spec.  Of course, there
> is a chance that the feature may actually not make it into F2028,
> or that there would be differences, but that is what experimental
> work is for.
>
> As for my motivation, I hate having to drop to C because Fortran
> lacks a feature :-)
>
> Everything will be hidden behind a flag, tentatively called
> -funsigned, to allow inclusion into the compiler at a later date.
>
> The amount of work will be substantial, but not too difficult - mostly
> copying and modifying what already works for integers
>
> Putting the work on a public branch probably works best; I will
> do so in the next few days. As name, I will use fortran_unsigned,
> unless somebody has a better idea.
>
> As to when this will be finished... I don't know, it could already
> be somewhat usable before being complete.  It is also work that can
> be split into many relatively small parts, just implementing one
> feature at a time.
>
> Best regards
>
> Thomas
>
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 09d1ebd95d2..4ff05a5c7dd 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -4340,7 +4340,7 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr *rvalue,
 
   /* The target must be either rank one or it must be simply contiguous
 	 and F2008 must be allowed.  */
-  if (rvalue->rank != 1)
+  if (rvalue->rank != 1 && rvalue->rank != -1)
 	{
 	  if (!gfc_is_simply_contiguous (rvalue, true, false))
 	{
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index de3d9e25911..dc4b737b647 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -2972,6 +2972,8 @@ typedef struct gfc_association_list
 
   gfc_expr *target;
 
+  gfc_array_ref *ar;
+
   /* Used for inferring the derived type of an associate name, whose selector
  is a sibling derived type function that has not yet been parsed.  */
   gfc_symbol *derived_types;
diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc
index c35f2bdd183..aef601cffcc 100644
--- a/gcc/fortran/intrinsic.cc
+++ b/gcc/fortran/intrinsic.cc
@@ -286,7 +286,8 @@ do_ts29113_check (gfc_intrinsic_sym *specific, gfc_actual_arglist *arg)
 		 &a->expr->where, gfc_current_intrinsic);
 	  ok = false;
 	}
-  else if (a->expr->rank == -1 && !specific->inquiry)
+  else if (a->expr->rank == -1
+	   && !(specific->inquiry || specific->id == GFC_ISYM_RESHAPE))
 	{
 	  gfc_error ("Assumed-rank argument at %L is only permitted as actual "
 		 "argument to intrinsic inquiry functions",
diff --git a/gcc/fortran/match.cc b/gcc/fortran/match.cc
index 1851a8f94a5..48a9d134b1a 100644
--- a/gcc/fortran/match.cc
+++ b/gcc/fortran/match.cc
@@ -1920,7 +1920,27 @@ gfc_match_associate (void)
   gfc_association_list* a;
 
   /* Match the next association.  */
-  if (gfc_match (" %n =>", newAssoc->name) != MATCH_YES)
+  if (gfc_match (" %n ", newAssoc->name) != MATCH_YES)
+	{
+	  /* "Expected associate name at %C" would be better.
+	  Change associate_3.f03 to match.  */
+	  gfc_error ("Expected association at %C");
+	  goto assocListError;
+	}
+
+  newAssoc->ar = gfc_get_array_ref ();
+
+  /* Required for an assumed rank target.  */
+  if (gfc_peek_char () == '('
+	  && gfc_match_array_ref (newAssoc->ar, NULL, 0,
+  GFC_MAX_DIMENSIONS) != MATCH_YES)
+	{
+	  gfc_error ("Bad array reference at %C");
+	  goto assocListError;
+	}
+
+  /* Match the next association.  */
+  if (gfc_match (" =>", newAssoc->name) != MATCH_YES)
 	{
 	  gfc_error ("Expected association at %C");
 	  goto assocListError;
diff --git a/gcc/fortran/parse.cc b/gcc/fortra