[PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]

[PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]

[Harald Anlauf]

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

Re: [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]

[Mikael Morin]

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

Re: [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]

[Harald Anlauf]

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
>

Re: [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]

[Mikael Morin]

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.

Re: [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]

[Harald Anlauf]

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

Re: [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]

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

[PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]

[Harald Anlauf]

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

Re: [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]

[Toon Moene]

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

Re: [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]

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

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

Re: [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]

[Harald Anlauf]

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

Re: [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]

[Harald Anlauf]

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

Re: [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]

[Harald Anlauf]

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,