From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) by sourceware.org (Postfix) with ESMTPS id 92348385695F for ; Sat, 17 Sep 2022 19:33:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 92348385695F 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.174.255]) by smtp.orange.fr with ESMTPA id ZdZ4oD9YWbJVVZdZBobQtt; Sat, 17 Sep 2022 21:33:30 +0200 X-ME-Helo: [192.168.1.17] X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Sat, 17 Sep 2022 21:33:30 +0200 X-ME-IP: 86.215.174.255 Content-Type: multipart/mixed; boundary="------------biDdlkLy533BzN7ZR0dOM40k" Message-ID: <3edab734-f5bb-5557-ff98-b0ce47d7c510@orange.fr> Date: Sat, 17 Sep 2022 21:33:22 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 From: Mikael Morin Subject: Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364] To: Thomas Koenig , Mikael Morin , gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org References: <20220916202439.549820-1-mikael@gcc.gnu.org> <20220916202439.549820-10-mikael@gcc.gnu.org> Content-Language: en-US In-Reply-To: X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,FREEMAIL_FROM,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,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 List-Id: This is a multi-part message in MIME format. --------------biDdlkLy533BzN7ZR0dOM40k Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Le 17/09/2022 à 19:03, Thomas Koenig via Fortran a écrit : > > Hi Mikael, > >> This adds support for clobbering of partial variable references, when >> they are passed as actual argument and the associated dummy has the >> INTENT(OUT) attribute. >> Support includes array elements, derived type component references, >> and complex real or imaginary parts. >> >> This is done by removing the check for lack of subreferences, which is >> basically a revert of r9-4911-gbd810d637041dba49a5aca3d085504575374ac6f. >> This removal allows more expressions than just array elements, >> components and complex parts, but the other expressions are excluded by >> other conditions: substrings are excluded by the check on expression >> type (CHARACTER is excluded), KIND and LEN references are rejected by >> the compiler as not valid in a variable definition context. >> >> The check for scalarness is also updated as it was only valid when there >> was no subreference. > > First, thanks a lot for digging into this subject. I have looked through > the patch series, and it looks very good so far. > > I have a concern about this part, though.  My understanding at the > time was that it is not possible to clobber an individual array > element, but that this clobbers anything off the pointer that this > is based on. > Well, we need the middle-end guys to give a definitive answer on this topic, but I think it would be a very penalizing limitation if that was the case. I have assumed that the clobber spanned the value it was applied on, neither more nor less, so just the array element in case of array elements. > So, > >   integer, dimension(3) :: a > >   a(1) = 1 >   a(3) = 3 >   call foo(a(1)) > > would also invalidate the store to a(3).  Is my understanding correct? I think it was the case before patch 2 in in the series, because the clobber was applied to the symbol decl, so in the case of the expression A(1), it was applied to A which is the full array. After patch 2, the clobber is applied to the expression A(1), so the element alone. > If so, I think this we cannot revert that patch (which was introduced > because of a regression). > The testcase from the patch was not specifically checking lack of side-effect clobbers, so I have double-checked with the following testcase, which should lift your concerns. I propose to keep the patch with the testcase added to it. What do you think? Mikael --------------biDdlkLy533BzN7ZR0dOM40k Content-Type: text/x-fortran; charset=UTF-8; name="intent_optimize_11.f90" Content-Disposition: attachment; filename="intent_optimize_11.f90" Content-Transfer-Encoding: base64 ISB7IGRnLWRvIHJ1biB9CiEgeyBkZy1hZGRpdGlvbmFsLW9wdGlvbnMgIi1mbm8taW5saW5l IC1mbm8taXBhLW1vZHJlZiAtZmR1bXAtdHJlZS1vcHRpbWl6ZWQgLWZkdW1wLXRyZWUtb3Jp Z2luYWwiIH0KIQohIFBSIGZvcnRyYW4vNDE0NTMKISBDaGVjayB0aGF0IHRoZSBJTlRFTlQo T1VUKSBhdHRyaWJ1dGUgY2F1c2VzIG9uZSBjbG9iYmVyIHRvIGJlIGVtaXR0ZWQKISBmb3Ig dGhlIGFycmF5IGVsZW1lbnQgcGFzc2VkIGFzIGFyZ3VtZW50IGluIHRoZSAqLm9yaWdpbmFs IGR1bXAsIGFuZCB0aGUKISBhc3NvY2lhdGVkIGluaXRpYWxpemF0aW9uIGNvbnN0YW50IHRv IGJlIG9wdGltaXplZCBhd2F5IGluIHRoZSAqLm9wdGltaXplZAohIGR1bXAsIHdoZXJlYXMg dGhlIG90aGVyIGluaXRpYWxpemF0aW9uIGNvbnN0YW50cyBhcmUgbm90IG9wdGltaXplZCBh d2F5LgoKbW9kdWxlIHgKaW1wbGljaXQgbm9uZQpjb250YWlucwogIHN1YnJvdXRpbmUgZm9v KGEpCiAgICBpbnRlZ2VyLCBpbnRlbnQob3V0KSA6OiBhCiAgICBhID0gNDIKICBlbmQgc3Vi cm91dGluZSBmb28KZW5kIG1vZHVsZSB4Cgpwcm9ncmFtIG1haW4KICB1c2UgeAogIGltcGxp Y2l0IG5vbmUKICBpbnRlZ2VyIDo6IGFjKDMpCgogIGFjKDEpID0gMTIzCiAgYWMoMikgPSA0 NTYKICBhYygzKSA9IDc4OQogIGNhbGwgZm9vKGFjKDIpKQogIGlmIChhbnkoYWMgLz0gWzEy MywgNDIsIDc4OV0pKSBzdG9wIDEKCmVuZCBwcm9ncmFtIG1haW4KCiEgeyBkZy1maW5hbCB7 IHNjYW4tdHJlZS1kdW1wLXRpbWVzICJDTE9CQkVSIiAxICJvcmlnaW5hbCIgfSB9CiEgeyBk Zy1maW5hbCB7IHNjYW4tdHJlZS1kdW1wICJhY1xcXFsxXFxcXSA9IHtDTE9CQkVSfTsiICJv cmlnaW5hbCIgfSB9CiEgeyBkZy1maW5hbCB7IHNjYW4tdHJlZS1kdW1wICAgICAiMTIzIiAi b3JpZ2luYWwiIH0gfQohIHsgZGctZmluYWwgeyBzY2FuLXRyZWUtZHVtcCAgICAgIjEyMyIg Im9wdGltaXplZCIgfSB9CiEgeyBkZy1maW5hbCB7IHNjYW4tdHJlZS1kdW1wICAgICAiNDU2 IiAib3JpZ2luYWwiIH0gfQohIHsgZGctZmluYWwgeyBzY2FuLXRyZWUtZHVtcC1ub3QgIjQ1 NiIgIm9wdGltaXplZCIgeyB0YXJnZXQgX19PUFRJTUlaRV9fIH0gfSB9CiEgeyBkZy1maW5h bCB7IHNjYW4tdHJlZS1kdW1wICAgICAiNzg5IiAib3JpZ2luYWwiIH0gfQohIHsgZGctZmlu YWwgeyBzY2FuLXRyZWUtZHVtcCAgICAgIjc4OSIgIm9wdGltaXplZCIgfSB9Cg== --------------biDdlkLy533BzN7ZR0dOM40k--