From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by sourceware.org (Postfix) with ESMTPS id 2E47F3858298; Thu, 18 Aug 2022 19:32:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2E47F3858298 X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.29] ([79.251.10.71]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MuUnK-1nXLLd3vOc-00rbgt; Thu, 18 Aug 2022 21:32:12 +0200 Message-ID: <9b7a9775-0b28-ecb2-bb0d-b41937627bda@gmx.de> Date: Thu, 18 Aug 2022 21:32:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652] Content-Language: en-US To: Mikael Morin , fortran@gcc.gnu.org, gcc-patches Newsgroups: gmane.comp.gcc.fortran References: <8e300265-e24c-59c2-19b0-3d74fc5ed425@orange.fr> <2c940b18-08f2-adeb-6ac3-22e89b72440d@orange.fr> <5504785b-7471-f51e-852a-5ef9b039cc21@orange.fr> From: Harald Anlauf In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:xy7vNQ0/mobo6Gu91dzw4KHZwy5+IkLUrPCWJiS+of+N8LtOslj ArzeYH7WwNzlVihgcwWQPjQx9TBh2o8SchhL/hA89BKLqEJvSxoVuYqp6FbFdwNqZrzzLmJ mwJcectM9z6yhwAIdBhYav7oVwv/KY3Pk/PyejqScuGpu7nD4IRL0la6eFmrJVsdSfZqYsP zz5sQu7BZYLZxQBTaj2kQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:g4uGGUog+3w=:mlse1d8TrIJWeoRyGGixLI a6ADZ5yEBEvEmnhxkuKfsOpq81ng3ooInFeol7q+qrh7MKBsZbq9X70NZkAYjkKgYw6s1TJwt iLeTjO9wC1ysgctq24dvW6njsFqfSJgwoQT7Qx+tcX6tpvB9npeuKpHRazwdb193fenG4xwHo eQyA5cCUd6RbZU7aAW46B6Vs6Fopyy6ujzeHuHW3mUfMMy8E+tZEkgMGYVtNdz3YH7d3Sv/v0 +6DLzmsGuso0b/HpwlZIARwwVK42imngQ8QN7anfmJ8ZvohdGXHuDLfgz/xm49Zi69ePEkIKr mDQ7ohYL6FFbAA8ayQAv5gj0b6yS6k5jMdwi4zNhNysjnUVr6CXjTaAe1wXGl0ll8tlg2SNUI ODTIHCETtGLgkMM68dQ5CYSZ4JpSHHhUaNkaFWgKIpDYZiS9pHpF2ncPcYsXw+V/Sxdukw1pY P92GRy96jPz8g7Ib2aYrJvqT130WuOoDelMLeKsyEfpJjV0qQzt9xhrvygKMkIpjL/T1ONnYB PvqrvQyAcMl1UVdYEM5TL6bJkL/p16uXFXpFNFO19p2ArgQMhj+Yh4/KZDTxbCBeBaAsyiiCX Mu4gJ0o2le/mLOKPLXLRRsc0sNIH6aqbd6BjjK3WbdGObqrC5QF1WVFEHR6NvUhbfaA/SuNcn XyFPEnOU5RbA9WzIx9Qq1q1jp4THSiXPUS4U8eay2k/n+mkCk2PyA0PI7DUf0xzwsIrvOgHH9 eBrsgmey/x9UIBY871fNKHkj9pbV9D8lYDjSpFi69Tjnrh9qVKhnsf/i8+SFzTkIOSIb3vx8C 5/ljidSMYxvz5pLZ5sRda+w6p9+k0YUAI4vVfe75XHhgnY/ffY4lDNrCYaKZ/WdddsbAj5LwU RbgbysfAL68MKw3yeF5k/J71Ge0YmX4vou+kIYstvrJ76GF2rH69cowF9g7HlEiHhkkc2vne+ C4hdQM4n1f/dK0K8HJX7jofVWinS0t6FMu+5VNkkH16rOXfnyFS8q80A3vCsHubPnHjZQyado tEmEiM0uHS1UAcs4hFIcjFgQbd/sULXI7yUSWjM05mTZ7TXzT8DeVsl7hnNCqxnxIvY+67cZ+ cilkLd80EFubxLAeO+PQlC88gHaT7PKysU5 X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham 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:16 -0000 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 =C3=A0 12:03, Mikael Morin a =C3=A9crit=C2=A0: >> Le 28/07/2022 =C3=A0 22:19, Mikael Morin a =C3=A9crit=C2=A0: >>> 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=E2=80=99m afraid we=E2=80=99ll have to revert. > > > -------- Message transf=C3=A9r=C3=A9 -------- > 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 =C3=A0 : '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 ran= ks > differ seeing as how the number of elements in the shape are not the sam= e, > 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 .FAL= SE. > > 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 a= re > not the same. ASSOCIATED is a much stronger test than mere address > comparison. > > (2) This text arises from an attempted, but failed, simplification of wh= at > we had before. Unfortunately, it is completely and utterly broken, as it > forbids the use of ASSOCIATED when POINTER is assumed-rank, has INTENT(I= N), > 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 TARG= ET > cannot ever be satisfied. > > However, the processor is not *required* to report an error when the ran= ks > 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 provid= ed > 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 o= n > TARGET, we can do so. Otherwise, we will need to wait until after Fortra= n > 2023 is published before we can restart the Defect Processing process. > > I will undertake to write a meeting paper addressing this issue before t= his > year's October meeting. If no paper has appeared by mid-September, pleas= e > feel free to remind me to do that! > > Cheers, 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,