From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by sourceware.org (Postfix) with ESMTPS id 283A3383A337; Mon, 25 Jul 2022 20:18:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 283A3383A337 X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [93.207.82.48] ([93.207.82.48]) by web-mail.gmx.net (3c-app-gmx-bs72.server.lan [172.19.170.208]) (via HTTP); Mon, 25 Jul 2022 22:18:06 +0200 MIME-Version: 1.0 Message-ID: From: Harald Anlauf To: Mikael Morin Cc: fortran , gcc-patches Subject: Re: [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652] Content-Type: text/plain; charset=UTF-8 Date: Mon, 25 Jul 2022 22:18:06 +0200 Importance: normal Sensitivity: Normal In-Reply-To: References: <8e300265-e24c-59c2-19b0-3d74fc5ed425@orange.fr> Content-Transfer-Encoding: quoted-printable X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:Ov1DM2ddHuXqzWq4anlMpYzWoUKP+OIUAarGzJJexi5q4FqnoIbQIKa4vka4gGLOM3mP7 XVE4DtfberFrlyKAJ3EoglCLE2Uk+8GsPeW56fycF5+V5cwK/udkoiZO5gycRIDiEMCCjurkoWtA wtXF7R8Cxh7HLRK89aL4YD7AVqJ/zfaIwMoiNr7Og3y/du6QcI3PS9NFvaWEtf//nqJJt9sQ0/ZZ d5fsLgEJ+Ul40V8AUfZqqgTLyDOvDu5IRYXIA+TfCsc6HzF6CNxGtWKU06YlV3CkYG9b7PLT04qo 8M= X-UI-Out-Filterresults: notjunk:1;V03:K0:nCr24m+VpS4=:cPXf3iKzAqIRVZiIrKKGna TmSd9BkVrNJaOi7M6M48536TKZDgSTCYu51/rRGlUjIYA6YVnJi5o/nFPzmvXuP6BGlJ4F1fW +9PTVH8gIH1gWharQFrqzFkulDsZTB/4m9xod/NK+p5mAwfPN554IZfQ9A+tJu7OktyCxXWWG Sao4zIKlQW3H4O+JooiepcC7b1+pwBCY4iDleqjNr7HtGerUnBjpKq+CbccDJxpm3tExruy1g MbONsPsumCp8MJcjDqsB4HdiBEqVWtRLEEgJnj+4zQO/5A1DOC9wEDTNkw2WtEuOsD8XoIick JVpeoWWypxqHZdkYMBVXtlmxoNymanPcMSA7bYapUe8OtIN5CdED1ckQc8JsD0EC8m5hIlxl/ s42tilRYESxE2G5pvX2rtWLLNRQwMu+LSC8x7wkY+s6jAkCGZhANrA41KDwStNWZPtGF0XnDx P4DIzUEldzeHcndiQv164wDyo+G1uYtu3uoZNoOtLuocxBBoHdCUV3oCQiqV2c6ncJz8peyoD Labo4nDLG+O9CwyGGXxW02IQxP+pZ1rONvV44WJl2EttAdYW8fvSF+P6NQ9xYUUs5M32/1Xs4 HSzajTeYkPqkQ98XFq8qPqb8tpqlpddILY0wYx0BPaMz6HjxSVhDe2DI7UcYeU7Yh3FXhJ9x8 P50tyW/MG6UOnMUYGWWtDm5TEx3vI2zzyTzGvpWQlcmDfYfSunlcorFSZC5DAjAjTlmaVfLsk SVv30uzx4G0G0kAwhJfd6aIHHOSm+rgjmvB0OK8LAsD1FzCxDoG5Z1NWIpE= X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP 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: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2022 20:18:10 -0000 Hi Mikael, > > https://community=2Eintel=2Ecom/t5/Intel-Fortran-Compiler/Intel-reject= s-ASSOCIATED-pointer-target-for-non-equal-ranks/m-p/1402799/highlight/true#= M162159 > >=20 >=20 > I disagree with the conclusion=2E Quoting Steve Lionel=E2=80=99s post: > > What you're missing is this: > >=20 > > TARGET (optional) shall be allowable as the data-target or proc-target= in a pointer assignment statement (10=2E2=2E2) in which POINTER is data-po= inter-object or proc-pointer-object=2E > >=20 > > We then go to 10=2E2=2E2 which says (emphasis mine): > >=20 > > C1019 (R1033) If bounds-remapping-list is not specified, the ranks of = data-pointer-object and data-target shall be the same=2E > >=20 > > So=2E=2E=2E not valid Fortran 2018=2E >=20 > except, that there is also this: > > C1018 (R1033) If bounds-remapping-list is specified, the number of bou= nds-remappings shall equal the rank of data-pointer-object=2E > which practically imposes no conformance rule between=20 > data-pointer-object and data-target=2E this is also why I initially thought that rank remapping is fine=2E > Note that in the syntax definition, bounds-remapping-list is not part of= =20 > data-pointer-object=2E In other words, by collating a=20 > bounds-remapping-list next to POINTER, one can construct an allowable=20 > pointer assignment from TARGET to POINTER, which satisfies the=20 > requirement, even if TARGET and POINTER don=E2=80=99t have the same rank= =2E I fully agree with you here=2E My current state of - sort-of - knowledge: - Crayftn 14=2E0 allows for rank remapping, accepts code the way you descr= ibe, including assumed-rank for the POINTER argument=2E - Nvidia 22=2E5 allows for rank remapping, but does not handle assumed-ran= k=2E - NAG 7=2E1 is said to reject non-equal rank=2E NAG 7=2E0 does not accept= it=2E - Intel rejects non-equal rank=2E Steve Lionel even thinks that assumed-r= ank should not be allowed here=2E I believe he is wrong here=2E I would normally trust NAG more than Intel and Cray=2E If somebody else c= onvinces me to accept that NAG has it wrong this time, I would be happy to proceed= =2E Apart from the above discussion about what the compiler should accept, the library side of gfortran seems to be fine=2E=2E=2E :-) Harald