From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out.smtpout.orange.fr (out-15.smtpout.orange.fr [193.252.22.15]) by sourceware.org (Postfix) with ESMTPS id 43E79385C6F7; Wed, 27 Mar 2024 15:30:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 43E79385C6F7 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gcc.gnu.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=gcc.gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 43E79385C6F7 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=193.252.22.15 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711553457; cv=none; b=SwhU9Jo9YsdM70Eac4CZIiTNhwVwtOA4HaEj807sYMBos+O/K5/up7H4wJ3cGzTGfRq9Dj4fBHdeFkfc2j8yPFTOeEO1GQMiZbbMV2ip5R6zNOLZRXXNgag+m6BCX6NPFaMX+Rr00ah9n3vLkrmPCic9c/Ee4+9/6B6cZhg85+A= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711553457; c=relaxed/simple; bh=O9yHXVtMlGGlwr49zi5vHHwFDtnYn/sG2vJgq4+3XGg=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=swiOcSQ0Qjw9Ek37MUSlwtKkLjETc5hncpK4TVq5Qk83YXDCj4o61XP9STZDF9AOJau7z+Tc/ocGNkz2ttjGm47B/4n1XaCaEDW167GWJ3x6uaXJgSvuqLUKyz3LBE78MlgK4MQYaey5MekZOUg8mWzgCZth7FL2OGVBPDkqCAY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from cyrano.home ([86.215.161.51]) by smtp.orange.fr with ESMTPA id pVEhrzFo0tI73pVEorjKkI; Wed, 27 Mar 2024 16:30:51 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wanadoo.fr; s=t20230301; t=1711553451; bh=rk321V+C4CXpHrL0cY8HRU14OAGQSnImfvRo9G1hrWY=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=WhvNE2/iUWmzMWOh6ntvjbbF+8KYvxoiARKaAzGUXM8t7lqIl14GF4TxZ9wxY2Fa9 6uMe/FswHsFNu19we9bF3tKlXDTRCw9YBiw2MtgHVAgQDe6cvSi1aj65BBhb7WmN4V 8wNLeCu78UqSu1wP3vLoKoMn7mkZg5bus6ka5xJV5Ug/PpOhzkqwHNBEnZSeUjw0hc sNCyFlx9/s2X5fcAiVGqGNiFeMsuJ/VHjcasEv8w+n9SypH2iiXfuaWjuFr2cTwtxU W7KcddpTflNVSuPq8sY+fgXKzKGuKCdMgJ3t/qIOSK6BnwZS0FEKcVPV4Wzj+j7jNq ixcENkSsD2iBg== X-ME-Helo: cyrano.home X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Wed, 27 Mar 2024 16:30:51 +0100 X-ME-IP: 86.215.161.51 From: Mikael Morin 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 Message-ID: <20240327153043.527359-1-mikael@gcc.gnu.org> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-10.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,FORGED_SPF_HELO,GIT_PATCH_0,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_NEUTRAL,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 --- 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 . + +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