public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Mikael Morin <morin-mikael@orange.fr>
To: Harald Anlauf <anlauf@gmx.de>, fortran@gcc.gnu.org
Subject: Re: [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]
Date: Thu, 4 Aug 2022 14:03:16 +0200	[thread overview]
Message-ID: <bc5517e6-e69e-35d2-e9b2-005aa9499a34@orange.fr> (raw)
In-Reply-To: <f2bce896-b3ef-b4c6-3267-ba870912849a@orange.fr>

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

  parent reply	other threads:[~2022-08-04 12:03 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           ` [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 [this message]
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=bc5517e6-e69e-35d2-e9b2-005aa9499a34@orange.fr \
    --to=morin-mikael@orange.fr \
    --cc=anlauf@gmx.de \
    --cc=fortran@gcc.gnu.org \
    /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).