From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cc-smtpout1.netcologne.de (cc-smtpout1.netcologne.de [89.1.8.211]) by sourceware.org (Postfix) with ESMTPS id 52DE33835564; Sun, 18 Sep 2022 10:23:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 52DE33835564 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=netcologne.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=netcologne.de Received: from cc-smtpin3.netcologne.de (cc-smtpin3.netcologne.de [89.1.8.203]) by cc-smtpout1.netcologne.de (Postfix) with ESMTP id C63DA12625; Sun, 18 Sep 2022 12:23:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=netcologne.de; s=nc1116a; t=1663496598; bh=XrNSEb1hD2JDBW+GC6eshnDk4EmXwFtNto4Fqr941tQ=; h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Mw4P8ykJ4iX/epRujnANimDj3jM8hh03Xl76ldv0pKhMmzo5OEFXry78+HXBzhmgz fmTLobv6jgfw0MydVdltPIg6+b12u0sBk08TJVo1guSSXXbZdpvhiaitUGXXVfmTP8 xzEbrVCHOnEShfgHNAB7uk/B3w4ewBhKBX4VhthWB94gxPT9swkeEx9A3p+5OYwIXw l1UNAFJiLkFAiq2RTuE9A7TcU8mrMNsqtqdqMT5l43FqvIkWZWa42ArTxMXpRrCpzP inV4hP8hR9Bg8rvXCjdTtfRahaLV+LkV9PDgURsMnIy1tN0rppHrwk1XwTtWJEL0fs Wmpqhg32mR2aA== Received: from [IPV6:2001:4dd7:1257:0:7285:c2ff:fe6c:992d] (2001-4dd7-1257-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de [IPv6:2001:4dd7:1257:0:7285:c2ff:fe6c:992d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by cc-smtpin3.netcologne.de (Postfix) with ESMTPSA id E958611DB8; Sun, 18 Sep 2022 12:23:13 +0200 (CEST) Message-ID: Date: Sun, 18 Sep 2022 12:23:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364] Content-Language: en-US To: Mikael Morin , Richard Biener Cc: 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> <3edab734-f5bb-5557-ff98-b0ce47d7c510@orange.fr> From: Thomas Koenig In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-NetCologne-Spam: L X-Spamd-Bar: ---- X-Rspamd-Queue-Id: E958611DB8 X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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: On 18.09.22 11:10, Mikael Morin wrote: > Le 18/09/2022 à 08:12, Richard Biener a écrit : >> On Sat, Sep 17, 2022 at 9:33 PM Mikael Morin >> wrote: >>> >>> Le 17/09/2022 à 19:03, Thomas Koenig via Fortran a écrit : >>>> >>>> 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. >> >> There is IL verification that the LHS of a CLOBBER is either >> a declaration or a pointer dereference, no array or component >> selection is allowed there.  Now, nothing should go wrong here, >> but we might eventually just drop those CLOBBERs or ICE if >> we frontend hands us an "invalid" one. >> > > Obviously I have assumed too much here; it's probably best to drop this > patch. Probably, yes. > It is unfortunate as there is some desirable behavior within reach here. I think some of the desired behavior can still be salvaged. For example, for subroutine foo(a,n) integer :: n integer, dimension(n), intent(in) :: n ... subroutine bar(a) integer, intent(out) :: a ... integer :: a(3) call foo(a,3) call foo(a(1),3) clobbers for the whole array can still be generated, but not for call foo(a(2),2) so one would have to look at the lower bound. For this case, it would be helpful to clobber a range a(2:), but that is a wishlist item for the future ;-) What is unsafe, currently, is call bar(a(1)) Best regards Thomas