Re: [PATCH] Fortran: fix DATA and derived types with pointer components [PR114474]
On 3/27/24 1:42 PM, Harald Anlauf wrote: Dear all, the attached patch fixes a 10+ regression for cases where a derived type with a pointer component is used in a DATA statement. The failure looked obscure, see testcase comments, and pointed to a possible issue in the resolution (order). For the failing test, the target variable was seen with ts.type == BT_PROCEDURE instead of its actual type. For this reason, I restricted the fixup as much as possible. For details, please see the commit message. Testcase cross-checked with NAG. Regtested on x86_64-pc-linux-gnu. OK for mainline? If this fix survives broader testing, I would like to backport. Thanks, Harald P.S.: while trying to extend coverage of conforming code, I had much fun also with other compilers (e.g. NAG panicking...) OK, for trunk and we will see how it survives for a bit before back port. Jerry -
[PATCH] Fortran: fix DATA and derived types with pointer components [PR114474]
Dear all,
the attached patch fixes a 10+ regression for cases where a
derived type with a pointer component is used in a DATA statement.
The failure looked obscure, see testcase comments, and pointed
to a possible issue in the resolution (order). For the failing
test, the target variable was seen with ts.type == BT_PROCEDURE
instead of its actual type. For this reason, I restricted the
fixup as much as possible.
For details, please see the commit message.
Testcase cross-checked with NAG.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
If this fix survives broader testing, I would like to backport.
Thanks,
Harald
P.S.: while trying to extend coverage of conforming code, I had
much fun also with other compilers (e.g. NAG panicking...)
From d5fda38243a22e1aef4367653d92521e53f2000d Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 27 Mar 2024 21:18:04 +0100
Subject: [PATCH] Fortran: fix DATA and derived types with pointer components
[PR114474]
When matching actual arguments in match_actual_arg, these are initially
treated as a possible dummy procedure, assuming that the correct type is
determined later. This resolution could fail when the procedure is a
derived type constructor with a pointer component and appears in a DATA
statement, where the pointer shall be associated with an initial data
target. Check for those cases where the type obviously has not been
resolved yet, and which were missed because there was no component
reference.
gcc/fortran/ChangeLog:
PR fortran/114474
* primary.cc (gfc_variable_attr): Catch variables used in structure
constructors within DATA statements that are still tagged with a
temporary type BT_PROCEDURE from match_actual_arg and which have the
target attribute, and fix their typespec.
gcc/testsuite/ChangeLog:
PR fortran/114474
* gfortran.dg/data_pointer_3.f90: New test.
---
gcc/fortran/primary.cc | 12 +++
gcc/testsuite/gfortran.dg/data_pointer_3.f90 | 77
2 files changed, 89 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/data_pointer_3.f90
diff --git a/gcc/fortran/primary.cc b/gcc/fortran/primary.cc
index 0ab69bb9dce..5dd6875a4a6 100644
--- a/gcc/fortran/primary.cc
+++ b/gcc/fortran/primary.cc
@@ -2804,6 +2804,18 @@ gfc_variable_attr (gfc_expr *expr, gfc_typespec *ts)
if (ts != NULL && expr->ts.type == BT_UNKNOWN)
*ts = sym->ts;
+ /* Catch left-overs from match_actual_arg, where an actual argument of a
+ procedure is given a temporary ts.type == BT_PROCEDURE. The fixup is
+ needed for structure constructors in DATA statements, where a pointer
+ is associated with a data target, and the argument has not been fully
+ resolved yet. Components references are dealt with further below. */
+ if (ts != NULL
+ && expr->ts.type == BT_PROCEDURE
+ && expr->ref == NULL
+ && attr.flavor != FL_PROCEDURE
+ && attr.target)
+*ts = sym->ts;
+
has_inquiry_part = false;
for (ref = expr->ref; ref; ref = ref->next)
if (ref->type == REF_INQUIRY)
diff --git a/gcc/testsuite/gfortran.dg/data_pointer_3.f90 b/gcc/testsuite/gfortran.dg/data_pointer_3.f90
new file mode 100644
index 000..f0325cd5bcb
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/data_pointer_3.f90
@@ -0,0 +1,77 @@
+! { dg-do compile }
+! PR fortran/114474 - DATA and derived types with pointer components
+
+program pr114474
+ implicit none
+ integer, target :: ii = 42! initial data target
+
+ integer, target :: jj = 24
+ integer, pointer:: qq => jj
+ ! ii and jj resolve slightly differently when the data statement below
+ ! is reached, as jj is resolved outside the structure constructor first
+
+ type t
+ integer, pointer :: h
+ end type t
+
+ integer, target :: kk(7) = 23
+ integer, pointer:: ll(:) => kk
+
+ type t1
+ integer :: m(7)
+ end type t1
+
+ type(t) :: x1, x2, x3, x4, x5
+ type(t), parameter :: z1 = t(null())
+
+ type(t1), target:: tt = t1([1,2,3,4,5,6,7])
+ type(t1), parameter :: vv = t1(22)
+ type(t1):: w1, w2
+ integer, pointer :: p1(:) => tt% m
+
+ data x1 / t(null()) /
+ data x2 / t(ii) / ! ii is initial data target
+ data x3 / t(jj) / ! jj is resolved differently...
+ data x4 / t(tt%m(3)) / ! pointer association with 3rd element
+
+ data w1 / t1(12) /
+ data w2 / t1(vv%m) /
+
+ if ( associated (x1% h)) stop 1
+ if (.not. associated (x2% h)) stop 2
+ if (.not. associated (x3% h)) stop 3
+ if (.not. associated (x4% h)) stop 4
+ if (x2% h /= 42) stop 5
+ if (x3% h /= 24) stop 6
+ if (x4% h /= 3) stop 7
+
+ if (any (w1%m /= 12 )) stop 8
+ if (any (w2%m /= vv%m)) stop 9
+end
+
+
+subroutine sub
+ implicit none
+
+ interface
+ real function myfun (x)
+ real, intent(in) :: x
+ end function myfun
+ end interface
+
+ type u
+ procedure(myfun), pointer, nopass :: p
+ end type u
+
+ type(u):: u3 = u(null())
+
Re: [PATCH] fortran: Fix specification expression check in submodules [PR114475]
On Wed, Mar 27, 2024 at 04:30:42PM +0100, Mikael Morin wrote: > 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? > Yes. Thank you (and Harald) for the quick fix. -- Steve
[PATCH] fortran: Fix specification expression check in submodules [PR114475]
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 000..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
