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 <malc...@nag-j.co.jp>
Pour : 'Mikael Morin' <morin-mik...@orange.fr>, sc22...@open-std.org
Copie à : 'Harald Anlauf' <anl...@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,
