From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr [80.12.242.124]) by sourceware.org (Postfix) with ESMTPS id 7FEB23858407 for ; Thu, 4 Aug 2022 12:03:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7FEB23858407 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orange.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=orange.fr Received: from [192.168.1.17] ([86.215.161.154]) by smtp.orange.fr with ESMTPA id JZZMoQ5RG9qatJZZNoljOF; Thu, 04 Aug 2022 14:03:18 +0200 X-ME-Helo: [192.168.1.17] X-ME-Auth: MDU4MTIxYWM4YWI0ZGE4ZTUwZWZmNTExZmI2ZWZlMThkM2ZhYiE5OWRkOGM= X-ME-Date: Thu, 04 Aug 2022 14:03:18 +0200 X-ME-IP: 86.215.161.154 Message-ID: Date: Thu, 4 Aug 2022 14:03:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652] Content-Language: en-US From: Mikael Morin To: Harald Anlauf , fortran@gcc.gnu.org References: <8e300265-e24c-59c2-19b0-3d74fc5ed425@orange.fr> <2c940b18-08f2-adeb-6ac3-22e89b72440d@orange.fr> <5504785b-7471-f51e-852a-5ef9b039cc21@orange.fr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00, FREEMAIL_FROM, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP 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, 04 Aug 2022 12:03:22 -0000 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, -- ..............Malcolm Cohen, NAG Oxford/Tokyo. -----Original Message----- From: Mikael Morin Sent: Wednesday, August 3, 2022 2:59 AM To: sc22wg5@open-std.org Cc: Harald Anlauf Subject: [ukfortran] [SC22WG5.6415] Request for interpretation of compile-time restrictions on ASSOCIATED Hello, we are contributors to gfortran. We have been discussing the restrictions a processor is required to put on ASSOCIATED functions calls with regards to rank mismatch in the thread at: > https://gcc.gnu.org/pipermail/fortran/2022-July/058012.html The following discussions are on the same topic as well: > https://groups.google.com/g/comp.lang.fortran/c/BQfpeDZxX3Q > https://community.intel.com/t5/Intel-Fortran-Compiler/Intel-rejects-ASSOCIAT ED-pointer-target-for-non-equal-ranks/m-p/1402799/highlight/true#M162159 The position from Steve Lionel in the latter threads is that a processor is required to reject an ASSOCIATED function call with arguments of mismatching ranks as there is no bounds-remapping list. Our understanding is that a processor shall accept it as long as it may accept a corresponding pointer association statement with additional bounds-remapping list. Our poll of existing compilers shows the same disagreement, with two accepting mismatching ranks (cray 14.0, nvidia 22.5) and two rejecting them (NAG 7.0 & 7.1, Intel). So we would like an official interpretation on this topic. More specifically, for each program below, is a processor (at compile time) required to reject it, allowed to reject it but not required to, or required to accept it? Thanks in advance. Harald Anlauf, Mikael Morin !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Example 1 ! matrix pointer vs array target program p real, dimension(100), target :: array real, dimension(:,:), pointer :: pmatrix => null() print *, associated(pmatrix, array) end !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Example 2 ! array pointer vs matrix target program p real, dimension(20,5), target :: matrix real, dimension(:), pointer :: parray => null() print *, associated(parray, matrix) end !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Example 3 ! array pointer vs rank 2 non-contiguous target program p real, dimension(20,5), target :: matrix real, dimension(:), pointer :: parray => null() print *, associated(parray, matrix(1:20:3, 1:5:2)) end !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Example 4 ! array pointer vs scalar target program p real, target :: scalar real, dimension(:), pointer :: parray => null() print *, associated(parray, scalar) end !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Example 5 ! scalar pointer vs array target program p real, dimension(100), target :: array real, pointer :: pscalar => null() print *, associated(pscalar, array) end !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Example 6 ! assumed rank (array) pointer vs matrix target program p real, dimension(20,5), target :: matrix real, dimension(:), pointer :: parray => null() call sub(parray) contains subroutine sub(ptr) real, pointer :: ptr(..) print *, associated(ptr, matrix) end subroutine sub end !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Example 7 ! assumed rank (scalar) pointer vs array target program p real, dimension(100), target :: array real, pointer :: pscalar => null() call sub(pscalar) contains subroutine sub(ptr) real, pointer :: ptr(..) print *, associated(ptr, array) end subroutine sub end !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Example 8 ! assumed rank (array) pointer vs scalar target program p real, target :: scalar real, dimension(:), pointer :: parray => null() call sub(parray) contains subroutine sub(ptr) real, pointer :: ptr(..) print *, associated(ptr, scalar) end subroutine sub end !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! _______________________________________________ ukfortran mailing list https://lists.accu.org/mailman/listinfo/ukfortran