From owner-sc22wg5+sc22wg5-dom9=www.open-std.org@open-std.org Thu Aug 4 10:55:08 2022 Return-Path: X-Original-To: sc22wg5-dom9 Delivered-To: sc22wg5-dom9@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id E9AEB358CEF; Thu, 4 Aug 2022 10:55:08 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr [80.12.242.124]) by www.open-std.org (Postfix) with ESMTP id AA892358C4E for ; Thu, 4 Aug 2022 10:55:07 +0200 (CEST) Received: from [192.168.1.17] ([86.215.161.154]) by smtp.orange.fr with ESMTPA id JWczo3MfPsfCIJWdFoMsxY; Thu, 04 Aug 2022 10:55:07 +0200 X-ME-Helo: [192.168.1.17] X-ME-Auth: MDU4MTIxYWM4YWI0ZGE4ZTUwZWZmNTExZmI2ZWZlMThkM2ZhYiE5OWRkOGM= X-ME-Date: Thu, 04 Aug 2022 10:55:07 +0200 X-ME-IP: 86.215.161.154 Message-ID: <5dbda2fc-d082-2845-81a0-5e004437b338@orange.fr> Date: Thu, 4 Aug 2022 10:54:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 From: Mikael Morin Subject: Re: [SC22WG5.6416] RE: [ukfortran] Request for interpretation of compile-time restrictions on ASSOCIATED To: Malcolm Cohen , sc22wg5@open-std.org Cc: 'Harald Anlauf' References: <20220802175930.8F3FD358D05@www.open-std.org> <20220804024959.CBCF1358D31@www.open-std.org> Content-Language: en-US In-Reply-To: <20220804024959.CBCF1358D31@www.open-std.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-sc22wg5@open-std.org Precedence: bulk Le 04/08/2022 à 04:43, Malcolm Cohen a écrit : > 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. > I see. In other words, ASSOCIATED doesn’t mean exactly the same as "POINTER and TARGET have been pointer-associated before". The semantics differs when bounds remapping is involved. > (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. > Well, the text is somewhat broken maybe, but to me it made some sense to allow to query any pair that can be pointer-associated. > 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. > Even if you can’t reach consensus on the normative text, a note or an example about bounds remapping would be appreciated as well. Thanks for your answer.