From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) by sourceware.org (Postfix) with ESMTPS id 24981385800E for ; Thu, 18 Aug 2022 19:32:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 24981385800E Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1oOlFX-0001Uj-Om for fortran@gcc.gnu.org; Thu, 18 Aug 2022 21:32:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: fortran@gcc.gnu.org From: Harald Anlauf 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 Message-ID: <9b7a9775-0b28-ecb2-bb0d-b41937627bda@gmx.de> References: <8e300265-e24c-59c2-19b0-3d74fc5ed425@orange.fr> <2c940b18-08f2-adeb-6ac3-22e89b72440d@orange.fr> <5504785b-7471-f51e-852a-5ef9b039cc21@orange.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Content-Language: en-US In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2022 19:32:21 -0000 Message-ID: <20220818193208.UwkfL7XJ3LmDJriUhz1bY-lfiS8GQVGfQt0gXhb__bI@z> 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 > Pour : 'Mikael Morin' , sc22wg5@open-std.org > Copie à : 'Harald Anlauf' > > 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,