public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]
@ 2022-07-21 20:12 Harald Anlauf
  2022-07-25 10:43 ` Mikael Morin
  0 siblings, 1 reply; 19+ messages in thread
From: Harald Anlauf @ 2022-07-21 20:12 UTC (permalink / raw)
  To: fortran, gcc-patches

[-- Attachment #1: Type: text/plain, Size: 274 bytes --]

Dear all,

the rank check for ASSOCIATED (POINTER, TARGET) did not allow all
rank combinations that were allowed in pointer assignment for
newer versions of the Fortran standard (F2008+).  Fix the logic.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

Thanks,
Harald


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fortran-fix-invalid-rank-error-in-ASSOCIATED-when-ra.patch --]
[-- Type: text/x-patch, Size: 3983 bytes --]

From 338b43aefece04435d32f961c33d217aaa511095 Mon Sep 17 00:00:00 2001
From: Harald Anlauf <anlauf@gmx.de>
Date: Thu, 21 Jul 2022 22:02:58 +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 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                          | 16 +++++++++--
 .../gfortran.dg/associated_target_9a.f90      | 27 +++++++++++++++++++
 .../gfortran.dg/associated_target_9b.f90      | 15 +++++++++++
 3 files changed, 56 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..6d3a4701950 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -1502,8 +1502,20 @@ 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 (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..ca62ab155c0
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/associated_target_9b.f90
@@ -0,0 +1,15 @@
+! { 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
+! matrix(1:20,1:5) => array
+! matrix2(1:100)   => array2
+  print *, associated (matrix, array ) ! Technically legal F2003
+  print *, associated (matrix2,array2) ! { dg-error "is not rank 1" }
+end
--
2.35.3


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]
  2022-07-21 20:12 [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652] Harald Anlauf
@ 2022-07-25 10:43 ` Mikael Morin
  2022-07-25 16:01   ` Harald Anlauf
  0 siblings, 1 reply; 19+ messages in thread
From: Mikael Morin @ 2022-07-25 10:43 UTC (permalink / raw)
  To: Harald Anlauf, fortran, gcc-patches

Le 21/07/2022 à 22:12, Harald Anlauf via Fortran a écrit :
> Dear all,
> 
> the rank check for ASSOCIATED (POINTER, TARGET) did not allow all
> rank combinations that were allowed in pointer assignment for
> newer versions of the Fortran standard (F2008+).  Fix the logic.
> 
So, if I understand correctly the (fixed) logic, it is:
  f2008+    => no check
  f2003     => check target’s rank different from 1
  up to f95 => check pointer’s rank equals target’s


I think one check is missing, that is when pointer is scalar and the 
target is non-scalar (either rank 1 or not).  This case should also be 
rejected for f2003+, not just up to f95.

Mikael

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]
  2022-07-25 10:43 ` Mikael Morin
@ 2022-07-25 16:01   ` Harald Anlauf
  2022-07-25 18:08     ` Mikael Morin
  0 siblings, 1 reply; 19+ messages in thread
From: Harald Anlauf @ 2022-07-25 16:01 UTC (permalink / raw)
  To: Mikael Morin; +Cc: fortran, gcc-patches

Hi Mikael, all,

a discussion in the Intel compiler forum suggests that the F2018
standard prohibits such use of the ASSOCIATED intrinsic.

https://community.intel.com/t5/Intel-Fortran-Compiler/Intel-rejects-ASSOCIATED-pointer-target-for-non-equal-ranks/m-p/1402799/highlight/true#M162159

As a consequence, the PR is likely invalid, as is the patch.
Withdrawing.

Sorry for the noise!

Harald


> Gesendet: Montag, 25. Juli 2022 um 12:43 Uhr
> Von: "Mikael Morin" <morin-mikael@orange.fr>
> An: "Harald Anlauf" <anlauf@gmx.de>, "fortran" <fortran@gcc.gnu.org>, "gcc-patches" <gcc-patches@gcc.gnu.org>
> Betreff: Re: [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]
>
> Le 21/07/2022 à 22:12, Harald Anlauf via Fortran a écrit :
> > Dear all,
> > 
> > the rank check for ASSOCIATED (POINTER, TARGET) did not allow all
> > rank combinations that were allowed in pointer assignment for
> > newer versions of the Fortran standard (F2008+).  Fix the logic.
> > 
> So, if I understand correctly the (fixed) logic, it is:
>   f2008+    => no check
>   f2003     => check target’s rank different from 1
>   up to f95 => check pointer’s rank equals target’s
> 
> 
> I think one check is missing, that is when pointer is scalar and the 
> target is non-scalar (either rank 1 or not).  This case should also be 
> rejected for f2003+, not just up to f95.
> 
> Mikael
>

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]
  2022-07-25 16:01   ` Harald Anlauf
@ 2022-07-25 18:08     ` Mikael Morin
  2022-07-25 20:18       ` Harald Anlauf
  0 siblings, 1 reply; 19+ messages in thread
From: Mikael Morin @ 2022-07-25 18:08 UTC (permalink / raw)
  To: Harald Anlauf; +Cc: fortran, gcc-patches

Le 25/07/2022 à 18:01, Harald Anlauf a écrit :
> Hi Mikael, all,
> 
> a discussion in the Intel compiler forum suggests that the F2018
> standard prohibits such use of the ASSOCIATED intrinsic.
> 
> https://community.intel.com/t5/Intel-Fortran-Compiler/Intel-rejects-ASSOCIATED-pointer-target-for-non-equal-ranks/m-p/1402799/highlight/true#M162159
> 

I disagree with the conclusion.  Quoting Steve Lionel’s post:
> What you're missing is this:
> 
> TARGET (optional) shall be allowable as the data-target or proc-target in a pointer assignment statement (10.2.2) in which POINTER is data-pointer-object or proc-pointer-object.
> 
> We then go to 10.2.2 which says (emphasis mine):
> 
> C1019 (R1033) If bounds-remapping-list is not specified, the ranks of data-pointer-object and data-target shall be the same.
> 
> So... not valid Fortran 2018.

except, that there is also this:
> C1018 (R1033) If bounds-remapping-list is specified, the number of bounds-remappings shall equal the rank of data-pointer-object.
which practically imposes no conformance rule between 
data-pointer-object and data-target.

Note that in the syntax definition, bounds-remapping-list is not part of 
data-pointer-object.  In other words, by collating a 
bounds-remapping-list next to POINTER, one can construct an allowable 
pointer assignment from TARGET to POINTER, which satisfies the 
requirement, even if TARGET and POINTER don’t have the same rank.


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]
  2022-07-25 18:08     ` Mikael Morin
@ 2022-07-25 20:18       ` Harald Anlauf
  2022-07-26 19:25         ` Mikael Morin
  0 siblings, 1 reply; 19+ messages in thread
From: Harald Anlauf @ 2022-07-25 20:18 UTC (permalink / raw)
  To: Mikael Morin; +Cc: fortran, gcc-patches

Hi Mikael,

> > https://community.intel.com/t5/Intel-Fortran-Compiler/Intel-rejects-ASSOCIATED-pointer-target-for-non-equal-ranks/m-p/1402799/highlight/true#M162159
> > 
> 
> I disagree with the conclusion.  Quoting Steve Lionel’s post:
> > What you're missing is this:
> > 
> > TARGET (optional) shall be allowable as the data-target or proc-target in a pointer assignment statement (10.2.2) in which POINTER is data-pointer-object or proc-pointer-object.
> > 
> > We then go to 10.2.2 which says (emphasis mine):
> > 
> > C1019 (R1033) If bounds-remapping-list is not specified, the ranks of data-pointer-object and data-target shall be the same.
> > 
> > So... not valid Fortran 2018.
> 
> except, that there is also this:
> > C1018 (R1033) If bounds-remapping-list is specified, the number of bounds-remappings shall equal the rank of data-pointer-object.
> which practically imposes no conformance rule between 
> data-pointer-object and data-target.

this is also why I initially thought that rank remapping is fine.

> Note that in the syntax definition, bounds-remapping-list is not part of 
> data-pointer-object.  In other words, by collating a 
> bounds-remapping-list next to POINTER, one can construct an allowable 
> pointer assignment from TARGET to POINTER, which satisfies the 
> requirement, even if TARGET and POINTER don’t have the same rank.

I fully agree with you here.

My current state of - sort-of - knowledge:

- Crayftn 14.0 allows for rank remapping, accepts code the way you describe,
  including assumed-rank for the POINTER argument.

- Nvidia 22.5 allows for rank remapping, but does not handle assumed-rank.

- NAG 7.1 is said to reject non-equal rank.  NAG 7.0 does not accept it.

- Intel rejects non-equal rank.  Steve Lionel even thinks that assumed-rank
  should not be allowed here.  I believe he is wrong here.

I would normally trust NAG more than Intel and Cray.  If somebody else convinces
me to accept that NAG has it wrong this time, I would be happy to proceed.

Apart from the above discussion about what the compiler should accept,
the library side of gfortran seems to be fine...  :-)

Harald


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]
  2022-07-25 20:18       ` Harald Anlauf
@ 2022-07-26 19:25         ` Mikael Morin
  2022-07-27 19:45           ` [PATCH, v2] " Harald Anlauf
  0 siblings, 1 reply; 19+ messages in thread
From: Mikael Morin @ 2022-07-26 19:25 UTC (permalink / raw)
  To: Harald Anlauf; +Cc: fortran, gcc-patches

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.


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]
  2022-07-26 19:25         ` Mikael Morin
@ 2022-07-27 19:45           ` Harald Anlauf
  2022-07-27 19:45             ` Harald Anlauf
                               ` (2 more replies)
  0 siblings, 3 replies; 19+ messages in thread
From: Harald Anlauf @ 2022-07-27 19:45 UTC (permalink / raw)
  To: Mikael Morin; +Cc: gcc-patches, fortran

[-- 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


^ permalink raw reply	[flat|nested] 19+ messages in thread

* [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]
  2022-07-27 19:45           ` [PATCH, v2] " Harald Anlauf
@ 2022-07-27 19:45             ` Harald Anlauf
  2022-07-27 19:50             ` Toon Moene
  2022-07-28 20:19             ` Mikael Morin
  2 siblings, 0 replies; 19+ messages in thread
From: Harald Anlauf @ 2022-07-27 19:45 UTC (permalink / raw)
  To: fortran; +Cc: gcc-patches

[-- 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


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]
  2022-07-27 19:45           ` [PATCH, v2] " Harald Anlauf
  2022-07-27 19:45             ` Harald Anlauf
@ 2022-07-27 19:50             ` Toon Moene
  2022-07-28 20:19             ` Mikael Morin
  2 siblings, 0 replies; 19+ messages in thread
From: Toon Moene @ 2022-07-27 19:50 UTC (permalink / raw)
  To: Harald Anlauf, fortran; +Cc: gcc-patches

On 7/27/22 21:45, Harald Anlauf via Fortran wrote:

> 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.
May I suggest that, if well known Fortran compilers differ in the 
treatment of this case, there might be reason to ask the Fortran 
Standard Committee for an Interpretation of the Standard ?

Kind regards,

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]
  2022-07-27 19:45           ` [PATCH, v2] " Harald Anlauf
  2022-07-27 19:45             ` 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-30 10:03               ` Mikael Morin
  2 siblings, 2 replies; 19+ messages in thread
From: Mikael Morin @ 2022-07-28 20:19 UTC (permalink / raw)
  To: Harald Anlauf, fortran; +Cc: gcc-patches, Toon Moene

Hello,

Le 27/07/2022 à 21:45, Harald Anlauf via Fortran a écrit :
> 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
> 
In principle, it could make sense to construct a one-sized array pointer 
(of any rank) pointing to a scalar, but I agree that if we follow the 
rules of the standard to the letter, it should be rejected (and we do 
reject such a pointer assignment).
So, with this case eliminated, this patch looks good to me as is.

Regarding Toon’s suggestion to ask the fortran committee, it sounds 
sensible.  I propose to prepare something tomorrow.




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]
  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
  1 sibling, 1 reply; 19+ messages in thread
From: Harald Anlauf @ 2022-07-29 20:01 UTC (permalink / raw)
  To: Mikael Morin, fortran; +Cc: gcc-patches

Am 28.07.22 um 22:19 schrieb Mikael Morin:
> Hello,
>
> Le 27/07/2022 à 21:45, Harald Anlauf via Fortran a écrit :
>> 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
>>
> In principle, it could make sense to construct a one-sized array pointer
> (of any rank) pointing to a scalar, but I agree that if we follow the
> rules of the standard to the letter, it should be rejected (and we do
> reject such a pointer assignment).
> So, with this case eliminated, this patch looks good to me as is.

OK, so I will push that version soon.

> Regarding Toon’s suggestion to ask the fortran committee, it sounds
> sensible.  I propose to prepare something tomorrow.
>

Depending on the answer we can later refine the compile-time check
and relax if needed.

Harald

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]
  2022-07-29 20:01               ` Harald Anlauf
@ 2022-07-29 20:01                 ` Harald Anlauf
  0 siblings, 0 replies; 19+ messages in thread
From: Harald Anlauf @ 2022-07-29 20:01 UTC (permalink / raw)
  To: fortran; +Cc: gcc-patches, fortran

Am 28.07.22 um 22:19 schrieb Mikael Morin:
> Hello,
> 
> Le 27/07/2022 à 21:45, Harald Anlauf via Fortran a écrit :
>> 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
>>
> In principle, it could make sense to construct a one-sized array pointer 
> (of any rank) pointing to a scalar, but I agree that if we follow the 
> rules of the standard to the letter, it should be rejected (and we do 
> reject such a pointer assignment).
> So, with this case eliminated, this patch looks good to me as is.

OK, so I will push that version soon.

> Regarding Toon’s suggestion to ask the fortran committee, it sounds 
> sensible.  I propose to prepare something tomorrow.
> 

Depending on the answer we can later refine the compile-time check
and relax if needed.

Harald


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]
  2022-07-28 20:19             ` Mikael Morin
  2022-07-29 20:01               ` Harald Anlauf
@ 2022-07-30 10:03               ` Mikael Morin
  2022-07-30 14:13                 ` Toon Moene
                                   ` (2 more replies)
  1 sibling, 3 replies; 19+ messages in thread
From: Mikael Morin @ 2022-07-30 10:03 UTC (permalink / raw)
  To: Harald Anlauf, fortran

Le 28/07/2022 à 22:19, Mikael Morin a écrit :
> I propose to prepare something tomorrow.
> 

Here you go.  I haven’t found a procedure, a template or guidelines on 
wg5-fortran.org, so I’m just asking questions as free text.
I have not put every combination of cases to limit the number of 
examples, but an answer for each example should give a good picture.
Anything to correct or change?  Anything to add?

Mikael


Hello,

we are contributors to gfortran.  We have been discussing the 
restrictions a processor is required to put on ASSOCIATED functions 
calls with regards to rank mismatch in the thread at:
> https://gcc.gnu.org/pipermail/fortran/2022-July/058012.html
The following discussions are on the same topic as well:
> https://groups.google.com/g/comp.lang.fortran/c/BQfpeDZxX3Q
> https://community.intel.com/t5/Intel-Fortran-Compiler/Intel-rejects-ASSOCIATED-pointer-target-for-non-equal-ranks/m-p/1402799/highlight/true#M162159

The position from Steve Lionel in the latter threads is that a processor 
is required to reject an ASSOCIATED function call with arguments of 
mismatching ranks as there is no bounds-remapping list.
Our understanding is that a processor shall accept it as long as it may 
accept a corresponding pointer association statement with additional 
bounds-remapping list.

Our poll of existing compilers shows the same disagreement, with two 
accepting mismatching ranks (cray 14.0, nvidia 22.5) and two rejecting 
them (NAG 7.0 & 7.1, Intel).

So we would like an official interpretation on this topic.
More specifically, for each program below, is a processor (at compile 
time) required to reject it, allowed to reject it but not required to, 
or required to accept it?

Harald Anlauf, Mikael Morin

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! Example 1
! matrix pointer vs array target
program p
   real, dimension(100),  target  :: array
   real, dimension(:,:),  pointer :: pmatrix => null()
   print *, associated(pmatrix, array)
end

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! Example 2
! array pointer vs matrix target
program p
   real, dimension(20,5), target  :: matrix
   real, dimension(:),    pointer :: parray => null()
   print *, associated(parray, matrix)
end

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! Example 3
! array pointer vs rank 2 non-contiguous target
program p
   real, dimension(20,5), target  :: matrix
   real, dimension(:),    pointer :: parray => null()
   print *, associated(parray, matrix(1:20:3, 1:5:2))
end

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! Example 4
! array pointer vs scalar target
program p
   real, target :: scalar
   real, dimension(:), pointer :: parray => null()
   print *, associated(parray, scalar)
end

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! Example 5
! scalar pointer vs array target
program p
   real, dimension(100), target :: array
   real, pointer :: pscalar => null()
   print *, associated(pscalar, array)
end

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! Example 6
! assumed rank (array) pointer vs matrix target
program p
   real, dimension(20,5), target  :: matrix
   real, dimension(:),    pointer :: parray => null()
   call sub(parray)
contains
   subroutine sub(ptr)
     real, pointer :: ptr(..)
     print *, associated(ptr, matrix)
   end subroutine sub
end

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! Example 7
! assumed rank (scalar) pointer vs array target
program p
   real, dimension(100), target :: array
   real, pointer :: pscalar => null()
   call sub(pscalar)
contains
   subroutine sub(ptr)
     real, pointer :: ptr(..)
     print *, associated(ptr, array)
   end subroutine sub
end

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! Example 8
! assumed rank (array) pointer vs scalar target
program p
   real, target :: scalar
   real, dimension(:), pointer :: parray => null()
   call sub(parray)
contains
   subroutine sub(ptr)
     real, pointer :: ptr(..)
     print *, associated(ptr, scalar)
   end subroutine sub
end

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]
  2022-07-30 10:03               ` Mikael Morin
@ 2022-07-30 14:13                 ` Toon Moene
  2022-07-30 18:35                 ` Harald Anlauf
  2022-08-04 12:03                 ` Mikael Morin
  2 siblings, 0 replies; 19+ messages in thread
From: Toon Moene @ 2022-07-30 14:13 UTC (permalink / raw)
  To: Mikael Morin, Harald Anlauf, fortran

Looks good to me.

Thanks !

Toon.

On 7/30/22 12:03, Mikael Morin wrote:

> Le 28/07/2022 à 22:19, Mikael Morin a écrit :
>> I propose to prepare something tomorrow.
>>
> 
> Here you go.  I haven’t found a procedure, a template or guidelines on 
> wg5-fortran.org, so I’m just asking questions as free text.
> I have not put every combination of cases to limit the number of 
> examples, but an answer for each example should give a good picture.
> Anything to correct or change?  Anything to add?
> 
> Mikael
> 
> 
> Hello,
> 
> we are contributors to gfortran.  We have been discussing the 
> restrictions a processor is required to put on ASSOCIATED functions 
> calls with regards to rank mismatch in the thread at:
>> https://gcc.gnu.org/pipermail/fortran/2022-July/058012.html
> The following discussions are on the same topic as well:
>> https://groups.google.com/g/comp.lang.fortran/c/BQfpeDZxX3Q
>> https://community.intel.com/t5/Intel-Fortran-Compiler/Intel-rejects-ASSOCIATED-pointer-target-for-non-equal-ranks/m-p/1402799/highlight/true#M162159 
>>
> 
> The position from Steve Lionel in the latter threads is that a processor 
> is required to reject an ASSOCIATED function call with arguments of 
> mismatching ranks as there is no bounds-remapping list.
> Our understanding is that a processor shall accept it as long as it may 
> accept a corresponding pointer association statement with additional 
> bounds-remapping list.
> 
> Our poll of existing compilers shows the same disagreement, with two 
> accepting mismatching ranks (cray 14.0, nvidia 22.5) and two rejecting 
> them (NAG 7.0 & 7.1, Intel).
> 
> So we would like an official interpretation on this topic.
> More specifically, for each program below, is a processor (at compile 
> time) required to reject it, allowed to reject it but not required to, 
> or required to accept it?
> 
> Harald Anlauf, Mikael Morin
> 
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> 
> ! Example 1
> ! matrix pointer vs array target
> program p
>    real, dimension(100),  target  :: array
>    real, dimension(:,:),  pointer :: pmatrix => null()
>    print *, associated(pmatrix, array)
> end
> 
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> 
> ! Example 2
> ! array pointer vs matrix target
> program p
>    real, dimension(20,5), target  :: matrix
>    real, dimension(:),    pointer :: parray => null()
>    print *, associated(parray, matrix)
> end
> 
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> 
> ! Example 3
> ! array pointer vs rank 2 non-contiguous target
> program p
>    real, dimension(20,5), target  :: matrix
>    real, dimension(:),    pointer :: parray => null()
>    print *, associated(parray, matrix(1:20:3, 1:5:2))
> end
> 
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> 
> ! Example 4
> ! array pointer vs scalar target
> program p
>    real, target :: scalar
>    real, dimension(:), pointer :: parray => null()
>    print *, associated(parray, scalar)
> end
> 
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> 
> ! Example 5
> ! scalar pointer vs array target
> program p
>    real, dimension(100), target :: array
>    real, pointer :: pscalar => null()
>    print *, associated(pscalar, array)
> end
> 
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> 
> ! Example 6
> ! assumed rank (array) pointer vs matrix target
> program p
>    real, dimension(20,5), target  :: matrix
>    real, dimension(:),    pointer :: parray => null()
>    call sub(parray)
> contains
>    subroutine sub(ptr)
>      real, pointer :: ptr(..)
>      print *, associated(ptr, matrix)
>    end subroutine sub
> end
> 
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> 
> ! Example 7
> ! assumed rank (scalar) pointer vs array target
> program p
>    real, dimension(100), target :: array
>    real, pointer :: pscalar => null()
>    call sub(pscalar)
> contains
>    subroutine sub(ptr)
>      real, pointer :: ptr(..)
>      print *, associated(ptr, array)
>    end subroutine sub
> end
> 
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> 
> ! Example 8
> ! assumed rank (array) pointer vs scalar target
> program p
>    real, target :: scalar
>    real, dimension(:), pointer :: parray => null()
>    call sub(parray)
> contains
>    subroutine sub(ptr)
>      real, pointer :: ptr(..)
>      print *, associated(ptr, scalar)
>    end subroutine sub
> end
> 
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]
  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
  2 siblings, 1 reply; 19+ messages in thread
From: Harald Anlauf @ 2022-07-30 18:35 UTC (permalink / raw)
  To: Mikael Morin, fortran

Hi Mikael,

Am 30.07.22 um 12:03 schrieb Mikael Morin:
> Le 28/07/2022 à 22:19, Mikael Morin a écrit :
>> I propose to prepare something tomorrow.
>>
>
> Here you go.  I haven’t found a procedure, a template or guidelines on
> wg5-fortran.org, so I’m just asking questions as free text.
> I have not put every combination of cases to limit the number of
> examples, but an answer for each example should give a good picture.
> Anything to correct or change?  Anything to add?
>
> Mikael

that pretty much covers all cases and looks good to me.

Thanks for taking this!

Harald

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]
  2022-07-30 18:35                 ` Harald Anlauf
@ 2022-07-30 18:35                   ` Harald Anlauf
  0 siblings, 0 replies; 19+ messages in thread
From: Harald Anlauf @ 2022-07-30 18:35 UTC (permalink / raw)
  To: fortran

Hi Mikael,

Am 30.07.22 um 12:03 schrieb Mikael Morin:
> Le 28/07/2022 à 22:19, Mikael Morin a écrit :
>> I propose to prepare something tomorrow.
>>
> 
> Here you go.  I haven’t found a procedure, a template or guidelines on 
> wg5-fortran.org, so I’m just asking questions as free text.
> I have not put every combination of cases to limit the number of 
> examples, but an answer for each example should give a good picture.
> Anything to correct or change?  Anything to add?
> 
> Mikael

that pretty much covers all cases and looks good to me.

Thanks for taking this!

Harald


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]
  2022-07-30 10:03               ` Mikael Morin
  2022-07-30 14:13                 ` Toon Moene
  2022-07-30 18:35                 ` Harald Anlauf
@ 2022-08-04 12:03                 ` Mikael Morin
  2022-08-18 19:32                   ` Harald Anlauf
  2 siblings, 1 reply; 19+ messages in thread
From: Mikael Morin @ 2022-08-04 12:03 UTC (permalink / raw)
  To: Harald Anlauf, fortran

Le 30/07/2022 à 12:03, Mikael Morin a écrit :
> Le 28/07/2022 à 22:19, Mikael Morin a écrit :
>> I propose to prepare something tomorrow.
>>
> 
> Here you go. 
> 

I posted the message the other day.
The mailing list archive are not automatic, so there is no link to the 
message (yet?), nor to the thread that follows it.
So I attach below the answer from Malcolm Cohen.
Long story short, he confirms the interpretation from Steve Lionel, and 
that the text in the standard needs fixing.
I’m afraid we’ll have to revert.


-------- Message transféré --------
Sujet : [SC22WG5.6416] RE: [ukfortran] Request for interpretation of 
compile-time restrictions on ASSOCIATED
Date : Thu, 4 Aug 2022 11:43:16 +0900
De : Malcolm Cohen <malcolm@nag-j.co.jp>
Pour : 'Mikael Morin' <morin-mikael@orange.fr>, sc22wg5@open-std.org
Copie à : 'Harald Anlauf' <anlauf@gmx.de>

Dear Mikael,

Thank you for your query.

I would agree with Steve Lionel that the ranks must be the same (when
POINTER is not assumed-rank), for two reasons.

(1) The result of ASSOCIATED is unambiguously .FALSE. when the shapes of
POINTER and TARGET differ. As the shapes cannot be the same when the ranks
differ seeing as how the number of elements in the shape are not the same,
that means it would always be .FALSE. when the ranks differ. The Fortran
language does not need an extra way to produce the LOGICAL constant .FALSE.

Note that this means that even in the case where POINTER is dimension (2,1)
and TARGET is dimension (1,2), and they both refer to the same elements in
array element order, ASSOCIATED will return .FALSE. because the shapes are
not the same. ASSOCIATED is a much stronger test than mere address
comparison.

(2) This text arises from an attempted, but failed, simplification of what
we had before. Unfortunately, it is completely and utterly broken, as it
forbids the use of ASSOCIATED when POINTER is assumed-rank, has INTENT(IN),
is PROTECTED (outside of its module), or is a pointer function reference.
That is because there are no pointer assignment statements where the pointer
object is permitted to be any of those, and thus the conditions for TARGET
cannot ever be satisfied.

However, the processor is not *required* to report an error when the ranks
differ, as this is not a "Constraint" in the standard. I would expect a high
quality implementation to do so, but maybe I just have high expectations...

It could also be a deliberate extension, with different semantics provided
by the processor. In that case, the processor would be required to have the
capability to report the use of the extension (but this need not be the
default).

Finally, I note that we are not accepting interpretation requests on Fortran
2018 at this time, as we are in the process of replacing it with a new
revision (Fortran 2023). However, we will certainly consider whether we can
make any correction to Fortran 2023 before publication (expected next year);
if there is consensus on how to fix the clearly-incorrect requirements on
TARGET, we can do so. Otherwise, we will need to wait until after Fortran
2023 is published before we can restart the Defect Processing process.

I will undertake to write a meeting paper addressing this issue before this
year's October meeting. If no paper has appeared by mid-September, please
feel free to remind me to do that!

Cheers,
-- 
..............Malcolm Cohen, NAG Oxford/Tokyo.

-----Original Message-----
From: Mikael Morin <morin-mikael@orange.fr> Sent: Wednesday, August 3, 
2022 2:59 AM
To: sc22wg5@open-std.org
Cc: Harald Anlauf <anlauf@gmx.de>
Subject: [ukfortran] [SC22WG5.6415] Request for interpretation of
compile-time restrictions on ASSOCIATED

Hello,

we are contributors to gfortran.  We have been discussing the restrictions a
processor is required to put on ASSOCIATED functions calls with regards to
rank mismatch in the thread at:
 > https://gcc.gnu.org/pipermail/fortran/2022-July/058012.html
The following discussions are on the same topic as well:
 > https://groups.google.com/g/comp.lang.fortran/c/BQfpeDZxX3Q
 >
https://community.intel.com/t5/Intel-Fortran-Compiler/Intel-rejects-ASSOCIAT
ED-pointer-target-for-non-equal-ranks/m-p/1402799/highlight/true#M162159

The position from Steve Lionel in the latter threads is that a processor is
required to reject an ASSOCIATED function call with arguments of mismatching
ranks as there is no bounds-remapping list.
Our understanding is that a processor shall accept it as long as it may
accept a corresponding pointer association statement with additional
bounds-remapping list.

Our poll of existing compilers shows the same disagreement, with two
accepting mismatching ranks (cray 14.0, nvidia 22.5) and two rejecting them
(NAG 7.0 & 7.1, Intel).

So we would like an official interpretation on this topic.
More specifically, for each program below, is a processor (at compile
time) required to reject it, allowed to reject it but not required to, or
required to accept it?

Thanks in advance.
Harald Anlauf, Mikael Morin

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! Example 1
! matrix pointer vs array target
program p
    real, dimension(100),  target  :: array
    real, dimension(:,:),  pointer :: pmatrix => null()
    print *, associated(pmatrix, array)
end

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! Example 2
! array pointer vs matrix target
program p
    real, dimension(20,5), target  :: matrix
    real, dimension(:),    pointer :: parray => null()
    print *, associated(parray, matrix)
end

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! Example 3
! array pointer vs rank 2 non-contiguous target program p
    real, dimension(20,5), target  :: matrix
    real, dimension(:),    pointer :: parray => null()
    print *, associated(parray, matrix(1:20:3, 1:5:2)) end

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! Example 4
! array pointer vs scalar target
program p
    real, target :: scalar
    real, dimension(:), pointer :: parray => null()
    print *, associated(parray, scalar)
end

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! Example 5
! scalar pointer vs array target
program p
    real, dimension(100), target :: array
    real, pointer :: pscalar => null()
    print *, associated(pscalar, array)
end

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! Example 6
! assumed rank (array) pointer vs matrix target program p
    real, dimension(20,5), target  :: matrix
    real, dimension(:),    pointer :: parray => null()
    call sub(parray)
contains
    subroutine sub(ptr)
      real, pointer :: ptr(..)
      print *, associated(ptr, matrix)
    end subroutine sub
end

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! Example 7
! assumed rank (scalar) pointer vs array target program p
    real, dimension(100), target :: array
    real, pointer :: pscalar => null()
    call sub(pscalar)
contains
    subroutine sub(ptr)
      real, pointer :: ptr(..)
      print *, associated(ptr, array)
    end subroutine sub
end

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! Example 8
! assumed rank (array) pointer vs scalar target program p
    real, target :: scalar
    real, dimension(:), pointer :: parray => null()
    call sub(parray)
contains
    subroutine sub(ptr)
      real, pointer :: ptr(..)
      print *, associated(ptr, scalar)
    end subroutine sub
end

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

_______________________________________________
ukfortran mailing list
https://lists.accu.org/mailman/listinfo/ukfortran

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]
  2022-08-04 12:03                 ` Mikael Morin
@ 2022-08-18 19:32                   ` Harald Anlauf
  2022-08-18 19:32                     ` Harald Anlauf
  0 siblings, 1 reply; 19+ messages in thread
From: Harald Anlauf @ 2022-08-18 19:32 UTC (permalink / raw)
  To: Mikael Morin, fortran, gcc-patches

Hi Mikael, all,

I've just reverted commit 0110cfd5449bae3a772f45ea2e4c5dab5b7a8ccd.
As it seems that commit ca170ed9f8a086ca7e1eec841882b6bed9ec1a3a did
not update bugzilla, I'll add a note to the PR and close it as invalid.

Thanks,
Harald


Am 04.08.22 um 14:03 schrieb Mikael Morin:
> Le 30/07/2022 à 12:03, Mikael Morin a écrit :
>> Le 28/07/2022 à 22:19, Mikael Morin a écrit :
>>> I propose to prepare something tomorrow.
>>>
>>
>> Here you go.
>
> I posted the message the other day.
> The mailing list archive are not automatic, so there is no link to the
> message (yet?), nor to the thread that follows it.
> So I attach below the answer from Malcolm Cohen.
> Long story short, he confirms the interpretation from Steve Lionel, and
> that the text in the standard needs fixing.
> I’m afraid we’ll have to revert.
>
>
> -------- Message transféré --------
> Sujet : [SC22WG5.6416] RE: [ukfortran] Request for interpretation of
> compile-time restrictions on ASSOCIATED
> Date : Thu, 4 Aug 2022 11:43:16 +0900
> De : Malcolm Cohen <malcolm@nag-j.co.jp>
> Pour : 'Mikael Morin' <morin-mikael@orange.fr>, sc22wg5@open-std.org
> Copie à : 'Harald Anlauf' <anlauf@gmx.de>
>
> Dear Mikael,
>
> Thank you for your query.
>
> I would agree with Steve Lionel that the ranks must be the same (when
> POINTER is not assumed-rank), for two reasons.
>
> (1) The result of ASSOCIATED is unambiguously .FALSE. when the shapes of
> POINTER and TARGET differ. As the shapes cannot be the same when the ranks
> differ seeing as how the number of elements in the shape are not the same,
> that means it would always be .FALSE. when the ranks differ. The Fortran
> language does not need an extra way to produce the LOGICAL constant .FALSE.
>
> Note that this means that even in the case where POINTER is dimension (2,1)
> and TARGET is dimension (1,2), and they both refer to the same elements in
> array element order, ASSOCIATED will return .FALSE. because the shapes are
> not the same. ASSOCIATED is a much stronger test than mere address
> comparison.
>
> (2) This text arises from an attempted, but failed, simplification of what
> we had before. Unfortunately, it is completely and utterly broken, as it
> forbids the use of ASSOCIATED when POINTER is assumed-rank, has INTENT(IN),
> is PROTECTED (outside of its module), or is a pointer function reference.
> That is because there are no pointer assignment statements where the
> pointer
> object is permitted to be any of those, and thus the conditions for TARGET
> cannot ever be satisfied.
>
> However, the processor is not *required* to report an error when the ranks
> differ, as this is not a "Constraint" in the standard. I would expect a
> high
> quality implementation to do so, but maybe I just have high expectations...
>
> It could also be a deliberate extension, with different semantics provided
> by the processor. In that case, the processor would be required to have the
> capability to report the use of the extension (but this need not be the
> default).
>
> Finally, I note that we are not accepting interpretation requests on
> Fortran
> 2018 at this time, as we are in the process of replacing it with a new
> revision (Fortran 2023). However, we will certainly consider whether we can
> make any correction to Fortran 2023 before publication (expected next
> year);
> if there is consensus on how to fix the clearly-incorrect requirements on
> TARGET, we can do so. Otherwise, we will need to wait until after Fortran
> 2023 is published before we can restart the Defect Processing process.
>
> I will undertake to write a meeting paper addressing this issue before this
> year's October meeting. If no paper has appeared by mid-September, please
> feel free to remind me to do that!
>
> Cheers,


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]
  2022-08-18 19:32                   ` Harald Anlauf
@ 2022-08-18 19:32                     ` Harald Anlauf
  0 siblings, 0 replies; 19+ messages in thread
From: Harald Anlauf @ 2022-08-18 19:32 UTC (permalink / raw)
  To: fortran

Hi Mikael, all,

I've just reverted commit 0110cfd5449bae3a772f45ea2e4c5dab5b7a8ccd.
As it seems that commit ca170ed9f8a086ca7e1eec841882b6bed9ec1a3a did
not update bugzilla, I'll add a note to the PR and close it as invalid.

Thanks,
Harald


Am 04.08.22 um 14:03 schrieb Mikael Morin:
> Le 30/07/2022 à 12:03, Mikael Morin a écrit :
>> Le 28/07/2022 à 22:19, Mikael Morin a écrit :
>>> I propose to prepare something tomorrow.
>>>
>>
>> Here you go.
> 
> I posted the message the other day.
> The mailing list archive are not automatic, so there is no link to the 
> message (yet?), nor to the thread that follows it.
> So I attach below the answer from Malcolm Cohen.
> Long story short, he confirms the interpretation from Steve Lionel, and 
> that the text in the standard needs fixing.
> I’m afraid we’ll have to revert.
> 
> 
> -------- Message transféré --------
> Sujet : [SC22WG5.6416] RE: [ukfortran] Request for interpretation of 
> compile-time restrictions on ASSOCIATED
> Date : Thu, 4 Aug 2022 11:43:16 +0900
> De : Malcolm Cohen <malcolm@nag-j.co.jp>
> Pour : 'Mikael Morin' <morin-mikael@orange.fr>, sc22wg5@open-std.org
> Copie à : 'Harald Anlauf' <anlauf@gmx.de>
> 
> Dear Mikael,
> 
> Thank you for your query.
> 
> I would agree with Steve Lionel that the ranks must be the same (when
> POINTER is not assumed-rank), for two reasons.
> 
> (1) The result of ASSOCIATED is unambiguously .FALSE. when the shapes of
> POINTER and TARGET differ. As the shapes cannot be the same when the ranks
> differ seeing as how the number of elements in the shape are not the same,
> that means it would always be .FALSE. when the ranks differ. The Fortran
> language does not need an extra way to produce the LOGICAL constant .FALSE.
> 
> Note that this means that even in the case where POINTER is dimension (2,1)
> and TARGET is dimension (1,2), and they both refer to the same elements in
> array element order, ASSOCIATED will return .FALSE. because the shapes are
> not the same. ASSOCIATED is a much stronger test than mere address
> comparison.
> 
> (2) This text arises from an attempted, but failed, simplification of what
> we had before. Unfortunately, it is completely and utterly broken, as it
> forbids the use of ASSOCIATED when POINTER is assumed-rank, has INTENT(IN),
> is PROTECTED (outside of its module), or is a pointer function reference.
> That is because there are no pointer assignment statements where the 
> pointer
> object is permitted to be any of those, and thus the conditions for TARGET
> cannot ever be satisfied.
> 
> However, the processor is not *required* to report an error when the ranks
> differ, as this is not a "Constraint" in the standard. I would expect a 
> high
> quality implementation to do so, but maybe I just have high expectations...
> 
> It could also be a deliberate extension, with different semantics provided
> by the processor. In that case, the processor would be required to have the
> capability to report the use of the extension (but this need not be the
> default).
> 
> Finally, I note that we are not accepting interpretation requests on 
> Fortran
> 2018 at this time, as we are in the process of replacing it with a new
> revision (Fortran 2023). However, we will certainly consider whether we can
> make any correction to Fortran 2023 before publication (expected next 
> year);
> if there is consensus on how to fix the clearly-incorrect requirements on
> TARGET, we can do so. Otherwise, we will need to wait until after Fortran
> 2023 is published before we can restart the Defect Processing process.
> 
> I will undertake to write a meeting paper addressing this issue before this
> year's October meeting. If no paper has appeared by mid-September, please
> feel free to remind me to do that!
> 
> Cheers,



^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2022-08-18 19:32 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-21 20:12 [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652] 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           ` [PATCH, v2] " Harald Anlauf
2022-07-27 19:45             ` 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

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).