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 C2F5D38582A0; Tue, 20 Sep 2022 06:54:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C2F5D38582A0 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-smtpin2.netcologne.de (cc-smtpin2.netcologne.de [89.1.8.202]) by cc-smtpout1.netcologne.de (Postfix) with ESMTP id 6E86112550; Tue, 20 Sep 2022 08:54:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=netcologne.de; s=nc1116a; t=1663656885; bh=KyftEQFjJM29ZcvHxxEvqnwuoTcqdv6UA9XlIpEg3rw=; h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Ck7dHKQGSSSqNJDtHK5swoPkGTG48OufZHtMn6Nk1BhQ9g66MstS/uJWd/tLs84c2 Oe9fPPenejjr/COIBp10LG5DyYLYJBCqEjJdmHvAIzhkAt7rC1I3zpgwShptKpnUjO g6xCSKuCwiivBwvyAzIQsyOdZ4iXZZLlATMX/wZK9x1trTvkuB+Ix5WLxA40a01ao6 /y6peXqEVP2UWyH9VswWQqVx3xzNmAMUfLz/5gdyLTdVXox4YLNoWPKVN46E58SRDJ eC38JmytGDLN1cx8A1hY/huwc7Q1Bvz2SWNX3kCAybp8Z/PcexPGgODDpz0scFIWI2 DjAs7C9QDclrQ== 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-smtpin2.netcologne.de (Postfix) with ESMTPSA id 7E65811DB5; Tue, 20 Sep 2022 08:54:39 +0200 (CEST) Message-ID: <10fc2a82-e23e-b488-66e3-9ef7c9e5d4ed@netcologne.de> Date: Tue, 20 Sep 2022 08:54:39 +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 , Harald Anlauf , 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> <3ef8c5c4-35a1-fa60-2a2d-a7bb3fbd35fc@gmx.de> <9996bd59-9cf1-12df-faa5-7d546e5732f7@orange.fr> <6ac60050-2298-df01-1345-d53c868ed5d9@gmx.de> <0a36f845-13fb-5046-7731-87f4832e8deb@orange.fr> From: Thomas Koenig In-Reply-To: <0a36f845-13fb-5046-7731-87f4832e8deb@orange.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-NetCologne-Spam: L X-Rspamd-Queue-Id: 7E65811DB5 X-Spamd-Bar: / X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,BODY_8BITS,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 19.09.22 22:50, Mikael Morin wrote: > Le 19/09/2022 à 21:46, Harald Anlauf a écrit : >> Am 18.09.22 um 22:55 schrieb Mikael Morin: >>> Le 18/09/2022 à 20:32, Harald Anlauf a écrit : >>>> >>>> Assumed shape will be on the easy side, >>>> while assumed size likely needs to be excluded for clobbering. >>>> >>> Isn’t it the converse that is true? >>> Assumed shape can be non-contiguous so have to be excluded, but assumed >>> size are contiguous, so valid candidates for clobbering. No? >> >> I really was referring here to *dummies*, as in the following example: >> >> program p >>    integer :: a(4) >>    a = 1 >>    call sub (a(1), 2) >>    print *, a >> contains >>    subroutine sub (b, k) >>      integer, intent(in)  :: k >>      integer, intent(out) :: b(*) >> !   integer, intent(out) :: b(k) >>      if (k > 2) b(k) = k >>    end subroutine sub >> end program p >> >> Assumed size (*) is just a contiguous hunk of memory of possibly >> unknown size, which can be zero.  So you couldn't set a clobber >> for the a(1) actual argument. >> > Couldn't you clobber A entirely?  If no element of B is initialized in > SUB, well, A has undefined values on return from SUB.  That's how > INTENT(OUT) works. Yes, I think so - you are passing the starting element of an array to an assumed-size array via storage association rules. It has to be an explicit interface, of course, otherwise it is unclear if an array or an array element is passed. Best regards Thomas