From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp-23.smtpout.orange.fr [80.12.242.23]) by sourceware.org (Postfix) with ESMTPS id 4D7933858D38 for ; Tue, 20 Sep 2022 08:46:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4D7933858D38 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 aYttodua0UoLVaYu1oTQ6u; Tue, 20 Sep 2022 10:46:50 +0200 X-ME-Helo: [192.168.1.17] X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Tue, 20 Sep 2022 10:46:50 +0200 X-ME-IP: 86.215.174.255 Message-ID: Date: Tue, 20 Sep 2022 10:46:41 +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 , Harald Anlauf 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> <10fc2a82-e23e-b488-66e3-9ef7c9e5d4ed@netcologne.de> Content-Language: en-US In-Reply-To: <10fc2a82-e23e-b488-66e3-9ef7c9e5d4ed@netcologne.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.1 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: Le 20/09/2022 à 08:54, Thomas Koenig a écrit : > > On 19.09.22 22:50, Mikael Morin wrote: >> Le 19/09/2022 à 21:46, Harald Anlauf a écrit : >>> >>> 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. > I have looked for the relevant excerpts from the standard. From 15.5.2.11 (sequence association): > If the dummy argument is not of type character > with default or C character kind, and the actual argument is an array element designator, the element sequence > consists of that array element and each element that follows it in array element order. > If the dummy argument is > assumed-size, the number of elements in the dummy argument is exactly the number of elements in the element > sequence. So the dummy size, even if not known to the programmer, is clearly defined (to the full array size in your example).