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

Message ID 20240722163528.3008a2ea@vepi2
State New
Headers
Series [Fortran,PR85510,v1] Fix coarray token in associate not linking |

Checks

Context Check Description
linaro-tcwg-bot/tcwg_gcc_build--master-arm fail Patch failed to apply
linaro-tcwg-bot/tcwg_gcc_build--master-aarch64 fail Patch failed to apply

Commit Message

Andre Vehreschild July 22, 2024, 2:35 p.m. UTC
  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
  

Comments

Andre Vehreschild Aug. 9, 2024, 2:32 p.m. UTC | #1
Ping!

And the last ping in the series. I have a "bigger" patch in the queue and want
the pending ones done beforehand.

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

- Andre

On Mon, 22 Jul 2024 16:35:28 +0200
Andre Vehreschild <vehre@gmx.de> wrote:

> 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


--
Andre Vehreschild * Email: vehre ad gmx dot de
  
Jerry D Aug. 9, 2024, 5:35 p.m. UTC | #2
Ok and thanks.

On Fri, Aug 9, 2024, 7:33 AM Andre Vehreschild <vehre@gmx.de> wrote:

> Ping!
>
> And the last ping in the series. I have a "bigger" patch in the queue and
> want
> the pending ones done beforehand.
>
> Regtested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
>
> - Andre
>
> On Mon, 22 Jul 2024 16:35:28 +0200
> Andre Vehreschild <vehre@gmx.de> wrote:
>
> > 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
>
>
> --
> Andre Vehreschild * Email: vehre ad gmx dot de
>
  
Andre Vehreschild Aug. 12, 2024, 8:45 a.m. UTC | #3
Hi Jerry,

thanks for the review. Commited as gcc-15-2882-g8d8db21eb72.

Thanks again and regards,
	Andre

On Fri, 9 Aug 2024 10:35:26 -0700
Jerry Delisle <jvdelisle2@gmail.com> wrote:

> Ok and thanks.
>
> On Fri, Aug 9, 2024, 7:33 AM Andre Vehreschild <vehre@gmx.de> wrote:
>
> > Ping!
> >
> > And the last ping in the series. I have a "bigger" patch in the queue and
> > want
> > the pending ones done beforehand.
> >
> > Regtested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
> >
> > - Andre
> >
> > On Mon, 22 Jul 2024 16:35:28 +0200
> > Andre Vehreschild <vehre@gmx.de> wrote:
> >
> > > 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
> >
> >
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
> >


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

Patch

From 5790f80089f3c4611bd50796ca53ed5437adf012 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild <vehre@gcc.gnu.org>
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 00000000000..c6777cad6ed
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray/pr85510.f90
@@ -0,0 +1,19 @@ 
+!{ dg-do run }
+
+! Contributed by Damian Rouson  <damian@archaeologic.codes>
+! 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