From: Harald Anlauf <anlauf@gmx.de>
To: Mikael Morin <morin-mikael@orange.fr>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>, fortran <fortran@gcc.gnu.org>
Subject: [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]
Date: Wed, 27 Jul 2022 21:45:46 +0200 [thread overview]
Message-ID: <aec53a51-4c11-d565-dc89-d6d63d3be0d8@gmx.de> (raw)
In-Reply-To: <2c940b18-08f2-adeb-6ac3-22e89b72440d@orange.fr>
[-- Attachment #1: Type: text/plain, Size: 1225 bytes --]
Hi Mikael,
Am 26.07.22 um 21:25 schrieb Mikael Morin:
> Le 25/07/2022 à 22:18, Harald Anlauf a écrit :
>> I would normally trust NAG more than Intel and Cray.
> … and yourself, it seems. Too bad.
>
>> If somebody else convinces me to accept that NAG has it wrong this
>> time, I would be happy to proceed.
> It won’t convince you about NAG, but here are two reasons to proceed:
> - Consensus among the maintainers is sufficient; it’s the case here.
> - If uncertain, let’s be rather too permissive than too strict; it’s
> fine as long as the runtime answer is right.
ok, I have thought about your comments in the review process,
and played with the Cray compiler. Attached is a refined version
of the patch that now rejects in addition these cases for which there
are no possible related pointer assignments with bounds remapping:
ASSOCIATED (scalar, array) ! impossible, cannot remap bounds
ASSOCIATED (array, scalar) ! a scalar is not simply contiguous
(Cray would allow those two, but IMHO these should be disallowed).
See attached for version 2 with updated testcase, regtested again.
I think this is what we could both be happy with... ;-)
Thanks,
Harald
[-- Attachment #2: pr77652-v2.diff --]
[-- Type: text/x-patch, Size: 4560 bytes --]
From 5432880ff21de862c64d79626aa19c4eda928cd5 Mon Sep 17 00:00:00 2001
From: Harald Anlauf <anlauf@gmx.de>
Date: Wed, 27 Jul 2022 21:34:22 +0200
Subject: [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is
remapped [PR77652]
gcc/fortran/ChangeLog:
PR fortran/77652
* check.cc (gfc_check_associated): Make the rank check of POINTER
vs. TARGET match the allowed forms of pointer assignment for the
selected Fortran standard.
gcc/testsuite/ChangeLog:
PR fortran/77652
* gfortran.dg/associated_target_9a.f90: New test.
* gfortran.dg/associated_target_9b.f90: New test.
---
gcc/fortran/check.cc | 23 ++++++++++++++--
.../gfortran.dg/associated_target_9a.f90 | 27 +++++++++++++++++++
.../gfortran.dg/associated_target_9b.f90 | 23 ++++++++++++++++
3 files changed, 71 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/associated_target_9a.f90
create mode 100644 gcc/testsuite/gfortran.dg/associated_target_9b.f90
diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index 91d87a1b2c1..1da0b3cbe15 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -1502,8 +1502,27 @@ gfc_check_associated (gfc_expr *pointer, gfc_expr *target)
t = false;
/* F2018 C838 explicitly allows an assumed-rank variable as the first
argument of intrinsic inquiry functions. */
- if (pointer->rank != -1 && !rank_check (target, 0, pointer->rank))
- t = false;
+ if (pointer->rank != -1 && pointer->rank != target->rank)
+ {
+ if (pointer->rank == 0 || target->rank == 0)
+ {
+ /* There exists no valid pointer assignment using bounds
+ remapping for scalar => array or array => scalar. */
+ if (!rank_check (target, 0, pointer->rank))
+ t = false;
+ }
+ else if (target->rank != 1)
+ {
+ if (!gfc_notify_std (GFC_STD_F2008, "Rank remapping target is not "
+ "rank 1 at %L", &target->where))
+ t = false;
+ }
+ else if ((gfc_option.allow_std & GFC_STD_F2003) == 0)
+ {
+ if (!rank_check (target, 0, pointer->rank))
+ t = false;
+ }
+ }
if (target->rank > 0 && target->ref)
{
for (i = 0; i < target->rank; i++)
diff --git a/gcc/testsuite/gfortran.dg/associated_target_9a.f90 b/gcc/testsuite/gfortran.dg/associated_target_9a.f90
new file mode 100644
index 00000000000..708645d5bcb
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/associated_target_9a.f90
@@ -0,0 +1,27 @@
+! { dg-do run }
+! { dg-options "-std=f2018" }
+! PR fortran/77652 - Invalid rank error in ASSOCIATED when rank is remapped
+! Contributed by Paul Thomas
+
+program p
+ real, dimension(100), target :: array
+ real, dimension(:,:), pointer :: matrix
+ real, dimension(20,5), target :: array2
+ real, dimension(:), pointer :: matrix2
+ matrix(1:20,1:5) => array
+ matrix2(1:100) => array2
+ !
+ ! F2018:16.9.16, ASSOCIATED (POINTER [, TARGET])
+ ! Case(v): If TARGET is present and is an array target, the result is
+ ! true if and only if POINTER is associated with a target that has
+ ! the same shape as TARGET, ...
+ if (associated (matrix, array )) stop 1
+ if (associated (matrix2,array2)) stop 2
+ call check (matrix2, array2)
+contains
+ subroutine check (ptr, tgt)
+ real, pointer :: ptr(..)
+ real, target :: tgt(:,:)
+ if (associated (ptr, tgt)) stop 3
+ end subroutine check
+end
diff --git a/gcc/testsuite/gfortran.dg/associated_target_9b.f90 b/gcc/testsuite/gfortran.dg/associated_target_9b.f90
new file mode 100644
index 00000000000..1daa0a7dde1
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/associated_target_9b.f90
@@ -0,0 +1,23 @@
+! { dg-do compile }
+! { dg-options "-std=f2003" }
+! PR fortran/77652 - Invalid rank error in ASSOCIATED when rank is remapped
+! Contributed by Paul Thomas
+
+subroutine s
+ real, dimension(100), target :: array
+ real, dimension(:,:), pointer :: matrix
+ real, dimension(20,5), target :: array2
+ real, dimension(:), pointer :: matrix2
+ real, pointer :: scalar, scalar2
+ scalar => scalar2
+ print *, associated (scalar, scalar2)
+
+ matrix(1:20,1:5) => array ! F2003+
+! matrix2(1:100) => array2 ! F2008+
+ print *, associated (matrix, array ) ! Technically legal F2003
+ print *, associated (matrix2,array2) ! { dg-error "is not rank 1" }
+
+ ! There exists no related valid pointer assignment for these cases:
+ print *, associated (scalar,matrix2) ! { dg-error "must be of rank 0" }
+ print *, associated (matrix2,scalar) ! { dg-error "must be of rank 1" }
+end
--
2.35.3
WARNING: multiple messages have this Message-ID
From: Harald Anlauf <anlauf@gmx.de>
To: fortran@gcc.gnu.org
Cc: gcc-patches@gcc.gnu.org
Subject: [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]
Date: Wed, 27 Jul 2022 21:45:46 +0200 [thread overview]
Message-ID: <aec53a51-4c11-d565-dc89-d6d63d3be0d8@gmx.de> (raw)
Message-ID: <20220727194546.J40zzcgy5k_YxuyI-kzGlT0V-gkEzCv5oCPa-gcEBQs@z> (raw)
In-Reply-To: <2c940b18-08f2-adeb-6ac3-22e89b72440d@orange.fr>
[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]
Hi Mikael,
Am 26.07.22 um 21:25 schrieb Mikael Morin:
> Le 25/07/2022 à 22:18, Harald Anlauf a écrit :
>> I would normally trust NAG more than Intel and Cray.
> … and yourself, it seems. Too bad.
>
>> If somebody else convinces me to accept that NAG has it wrong this
>> time, I would be happy to proceed.
> It won’t convince you about NAG, but here are two reasons to proceed:
> - Consensus among the maintainers is sufficient; it’s the case here.
> - If uncertain, let’s be rather too permissive than too strict; it’s
> fine as long as the runtime answer is right.
ok, I have thought about your comments in the review process,
and played with the Cray compiler. Attached is a refined version
of the patch that now rejects in addition these cases for which there
are no possible related pointer assignments with bounds remapping:
ASSOCIATED (scalar, array) ! impossible, cannot remap bounds
ASSOCIATED (array, scalar) ! a scalar is not simply contiguous
(Cray would allow those two, but IMHO these should be disallowed).
See attached for version 2 with updated testcase, regtested again.
I think this is what we could both be happy with... ;-)
Thanks,
Harald
[-- Attachment #2: pr77652-v2.diff --]
[-- Type: text/x-patch, Size: 4560 bytes --]
From 5432880ff21de862c64d79626aa19c4eda928cd5 Mon Sep 17 00:00:00 2001
From: Harald Anlauf <anlauf@gmx.de>
Date: Wed, 27 Jul 2022 21:34:22 +0200
Subject: [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is
remapped [PR77652]
gcc/fortran/ChangeLog:
PR fortran/77652
* check.cc (gfc_check_associated): Make the rank check of POINTER
vs. TARGET match the allowed forms of pointer assignment for the
selected Fortran standard.
gcc/testsuite/ChangeLog:
PR fortran/77652
* gfortran.dg/associated_target_9a.f90: New test.
* gfortran.dg/associated_target_9b.f90: New test.
---
gcc/fortran/check.cc | 23 ++++++++++++++--
.../gfortran.dg/associated_target_9a.f90 | 27 +++++++++++++++++++
.../gfortran.dg/associated_target_9b.f90 | 23 ++++++++++++++++
3 files changed, 71 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/associated_target_9a.f90
create mode 100644 gcc/testsuite/gfortran.dg/associated_target_9b.f90
diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index 91d87a1b2c1..1da0b3cbe15 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -1502,8 +1502,27 @@ gfc_check_associated (gfc_expr *pointer, gfc_expr *target)
t = false;
/* F2018 C838 explicitly allows an assumed-rank variable as the first
argument of intrinsic inquiry functions. */
- if (pointer->rank != -1 && !rank_check (target, 0, pointer->rank))
- t = false;
+ if (pointer->rank != -1 && pointer->rank != target->rank)
+ {
+ if (pointer->rank == 0 || target->rank == 0)
+ {
+ /* There exists no valid pointer assignment using bounds
+ remapping for scalar => array or array => scalar. */
+ if (!rank_check (target, 0, pointer->rank))
+ t = false;
+ }
+ else if (target->rank != 1)
+ {
+ if (!gfc_notify_std (GFC_STD_F2008, "Rank remapping target is not "
+ "rank 1 at %L", &target->where))
+ t = false;
+ }
+ else if ((gfc_option.allow_std & GFC_STD_F2003) == 0)
+ {
+ if (!rank_check (target, 0, pointer->rank))
+ t = false;
+ }
+ }
if (target->rank > 0 && target->ref)
{
for (i = 0; i < target->rank; i++)
diff --git a/gcc/testsuite/gfortran.dg/associated_target_9a.f90 b/gcc/testsuite/gfortran.dg/associated_target_9a.f90
new file mode 100644
index 00000000000..708645d5bcb
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/associated_target_9a.f90
@@ -0,0 +1,27 @@
+! { dg-do run }
+! { dg-options "-std=f2018" }
+! PR fortran/77652 - Invalid rank error in ASSOCIATED when rank is remapped
+! Contributed by Paul Thomas
+
+program p
+ real, dimension(100), target :: array
+ real, dimension(:,:), pointer :: matrix
+ real, dimension(20,5), target :: array2
+ real, dimension(:), pointer :: matrix2
+ matrix(1:20,1:5) => array
+ matrix2(1:100) => array2
+ !
+ ! F2018:16.9.16, ASSOCIATED (POINTER [, TARGET])
+ ! Case(v): If TARGET is present and is an array target, the result is
+ ! true if and only if POINTER is associated with a target that has
+ ! the same shape as TARGET, ...
+ if (associated (matrix, array )) stop 1
+ if (associated (matrix2,array2)) stop 2
+ call check (matrix2, array2)
+contains
+ subroutine check (ptr, tgt)
+ real, pointer :: ptr(..)
+ real, target :: tgt(:,:)
+ if (associated (ptr, tgt)) stop 3
+ end subroutine check
+end
diff --git a/gcc/testsuite/gfortran.dg/associated_target_9b.f90 b/gcc/testsuite/gfortran.dg/associated_target_9b.f90
new file mode 100644
index 00000000000..1daa0a7dde1
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/associated_target_9b.f90
@@ -0,0 +1,23 @@
+! { dg-do compile }
+! { dg-options "-std=f2003" }
+! PR fortran/77652 - Invalid rank error in ASSOCIATED when rank is remapped
+! Contributed by Paul Thomas
+
+subroutine s
+ real, dimension(100), target :: array
+ real, dimension(:,:), pointer :: matrix
+ real, dimension(20,5), target :: array2
+ real, dimension(:), pointer :: matrix2
+ real, pointer :: scalar, scalar2
+ scalar => scalar2
+ print *, associated (scalar, scalar2)
+
+ matrix(1:20,1:5) => array ! F2003+
+! matrix2(1:100) => array2 ! F2008+
+ print *, associated (matrix, array ) ! Technically legal F2003
+ print *, associated (matrix2,array2) ! { dg-error "is not rank 1" }
+
+ ! There exists no related valid pointer assignment for these cases:
+ print *, associated (scalar,matrix2) ! { dg-error "must be of rank 0" }
+ print *, associated (matrix2,scalar) ! { dg-error "must be of rank 1" }
+end
--
2.35.3
next prev parent reply other threads:[~2022-07-27 19:45 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-21 20:12 [PATCH] " Harald Anlauf
2022-07-25 10:43 ` Mikael Morin
2022-07-25 16:01 ` Harald Anlauf
2022-07-25 18:08 ` Mikael Morin
2022-07-25 20:18 ` Harald Anlauf
2022-07-26 19:25 ` Mikael Morin
2022-07-27 19:45 ` Harald Anlauf [this message]
2022-07-27 19:45 ` [PATCH, v2] " Harald Anlauf
2022-07-27 19:50 ` Toon Moene
2022-07-28 20:19 ` Mikael Morin
2022-07-29 20:01 ` Harald Anlauf
2022-07-29 20:01 ` Harald Anlauf
2022-07-30 10:03 ` Mikael Morin
2022-07-30 14:13 ` Toon Moene
2022-07-30 18:35 ` Harald Anlauf
2022-07-30 18:35 ` Harald Anlauf
2022-08-04 12:03 ` Mikael Morin
2022-08-18 19:32 ` Harald Anlauf
2022-08-18 19:32 ` Harald Anlauf
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=aec53a51-4c11-d565-dc89-d6d63d3be0d8@gmx.de \
--to=anlauf@gmx.de \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=morin-mikael@orange.fr \
/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).