public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Mikael Morin <mikael@gcc.gnu.org>
To: fortran@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: [PATCH] fortran: Fix specification expression check in submodules [PR114475]
Date: Wed, 27 Mar 2024 16:30:42 +0100	[thread overview]
Message-ID: <20240327153043.527359-1-mikael@gcc.gnu.org> (raw)

Hell(o),

it didn't take long for my recent patch for PR111781 to show a regression.
The fix proposed here is actually the one Harald posted in the PR.
I can't imagine a case where it wouldn't do the right thing.
Regression tested on x86_64-pc-linux-gnu.
OK for master?

-- >8 --

The patch fixing PR111781 made the check of specification expressions more
restrictive, disallowing local variables in specification expressions of
dummy arguments.  PR114475 showed an example where that change regressed,
disallowing in submodules expressions that had been allowed in the parent
module.  In submodules indeed, the hierarchy of namespaces inherited from
the parent module is not reproduced so the host-association of symbols
can't be recognized by checking the nesting of namespaces.

This change fixes the problem by allowing in specification expressions
all the symbols in a submodule that are inherited from the parent module.

	PR fortran/111781
	PR fortran/114475

gcc/fortran/ChangeLog:

	* expr.cc (check_restricted): In submodules, allow variables host-
	associated from the parent module.

gcc/testsuite/ChangeLog:

	* gfortran.dg/spec_expr_10.f90: New test.

Co-authored-by: Harald Anlauf <anlauf@gmx.de>
---
 gcc/fortran/expr.cc                        |  1 +
 gcc/testsuite/gfortran.dg/spec_expr_10.f90 | 46 ++++++++++++++++++++++
 2 files changed, 47 insertions(+)
 create mode 100644 gcc/testsuite/gfortran.dg/spec_expr_10.f90

diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 9a042cd7040..09d1ebd95d2 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -3517,6 +3517,7 @@ check_restricted (gfc_expr *e)
       if (e->error
 	    || sym->attr.in_common
 	    || sym->attr.use_assoc
+	    || sym->attr.used_in_submodule
 	    || sym->attr.dummy
 	    || sym->attr.implied_index
 	    || sym->attr.flavor == FL_PARAMETER
diff --git a/gcc/testsuite/gfortran.dg/spec_expr_10.f90 b/gcc/testsuite/gfortran.dg/spec_expr_10.f90
new file mode 100644
index 00000000000..287b5a8d6cc
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/spec_expr_10.f90
@@ -0,0 +1,46 @@
+! { dg-do compile }
+!
+! PR fortran/114475
+! The array specification of PP in OL_EVAL used to be rejected in the submodule
+! because the compiler was not able to see the host-association of N_EXTERNAL
+! there.
+!
+! Contributed by Jürgen Reuter <juergen.reuter@desy.de>.
+
+module t1
+  use, intrinsic :: iso_c_binding
+  implicit none
+  private
+  public :: t1_t
+  integer :: N_EXTERNAL = 0
+
+  type :: t1_t
+  contains
+    procedure :: set_n_external => t1_set_n_external
+  end type t1_t
+
+  abstract interface
+     subroutine ol_eval (id, pp, emitter) bind(C)
+       import
+       real(kind = c_double), intent(in) :: pp(5 * N_EXTERNAL)
+     end subroutine ol_eval
+  end interface
+  interface
+    module subroutine t1_set_n_external (object, n)
+      class(t1_t), intent(inout) :: object
+      integer, intent(in) :: n
+    end subroutine t1_set_n_external
+  end interface
+
+end module t1
+
+submodule (t1) t1_s
+  implicit none
+contains
+  module subroutine t1_set_n_external (object, n)
+    class(t1_t), intent(inout) :: object
+    integer, intent(in) :: n
+    N_EXTERNAL = n
+  end subroutine t1_set_n_external
+
+end submodule t1_s
-- 
2.43.0


             reply	other threads:[~2024-03-27 15:30 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-27 15:30 Mikael Morin [this message]
2024-03-27 16:43 ` Steve Kargl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240327153043.527359-1-mikael@gcc.gnu.org \
    --to=mikael@gcc.gnu.org \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).