public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Harald Anlauf <anlauf@gmx.de>
To: fortran@gcc.gnu.org
Subject: Re: [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]
Date: Thu, 18 Aug 2022 21:32:08 +0200	[thread overview]
Message-ID: <9b7a9775-0b28-ecb2-bb0d-b41937627bda@gmx.de> (raw)
Message-ID: <20220818193208.UwkfL7XJ3LmDJriUhz1bY-lfiS8GQVGfQt0gXhb__bI@z> (raw)
In-Reply-To: <bc5517e6-e69e-35d2-e9b2-005aa9499a34@orange.fr>

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,



  reply	other threads:[~2022-08-18 19:32 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
2022-08-18 19:32                   ` Harald Anlauf [this message]
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=9b7a9775-0b28-ecb2-bb0d-b41937627bda@gmx.de \
    --to=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).