From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) by sourceware.org (Postfix) with ESMTPS id 93D08395C023; Sun, 18 Sep 2022 06:12:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 93D08395C023 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ej1-x633.google.com with SMTP id lh5so16008915ejb.10; Sat, 17 Sep 2022 23:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date; bh=CqZkRyI95GBP+GXcB8SQUgaVXOjCTyha3rHKfloA6s8=; b=Pz5SCZUS3MHgRgoPviu7tj3It2ZU/irG3/EKnGq7hZOMayV3AUgjjOHndSD0NuvHo9 AIJo167MHHIyykFRi9ALGq8XalMj9+z03WedTwsmgK2D7xs/AAVF2QB5Z0zOvNaZP/rP 3kSVFA+NSfnEI5egVyJEAm24U00PCK5HJX3+b5nQI3uX+gwr0U1AxPHUFnzv/QEXVU/h hMZ5bX4mL2lH3NqbnPvcwttKAyqUYK8j1v7mI+SQUg3ngxGcXK1I5kJnpVHQMqVwLlzW t9wwYpZroL1EnN6SqD69bvgKQOrATcLQOp+ep2bepCUHmfiAxbyEg5Fo+ASj0waFHaNm GnhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=CqZkRyI95GBP+GXcB8SQUgaVXOjCTyha3rHKfloA6s8=; b=SX9G2RNaZNhabJRfNt/nrNlcoLP/9aiO0wDlk8yXqqGNryHJPSnroHEi0cfTUfWh8l dlclHtbm2op2MVd1zXLzLfI7kW5QPaYqCxKlY9DmVESixbIs46mJzFdC5+7iZ6Ea8goM S7JSrHm8Q/YgLf78OcriPJ8n01AMAJF4gCFD7NUBfpesC6wJ+KRIE3oZlr67uC8TJ2N1 tanmBpMAc5/BYM4eg30j+rYstA8kQB6tD9FJujz4Ezr7AdCom7QzGmrNDHAHOAq0TPI+ Ok6Y5GXeNEt9Q5DBy7KqZk8jekahKH7K7KjFmSWfHJkj4Es3IB2hwKhzRbDLRueXa1t/ irHg== X-Gm-Message-State: ACrzQf0blEqWDlP/+j3BEV098ot4b3rECK7E6OxIMJlHeh1y1PcniVaj 1UlhE9ZIGONDC0b0s3hfDDQb/QzdvX2xSpHPpNE= X-Google-Smtp-Source: AMsMyM5id2qeLWGaktRSdpqf4iIfyIRX/8zF9OrWB3dR3OuL7Rgjr7ou0AjZF1/HitkAg1QqKvKYL7giwOJtnfQ/Y4U= X-Received: by 2002:a17:907:94c6:b0:77d:7ad3:d063 with SMTP id dn6-20020a17090794c600b0077d7ad3d063mr8667263ejc.330.1663481558086; Sat, 17 Sep 2022 23:12:38 -0700 (PDT) MIME-Version: 1.0 References: <20220916202439.549820-1-mikael@gcc.gnu.org> <20220916202439.549820-10-mikael@gcc.gnu.org> <3edab734-f5bb-5557-ff98-b0ce47d7c510@orange.fr> In-Reply-To: <3edab734-f5bb-5557-ff98-b0ce47d7c510@orange.fr> From: Richard Biener Date: Sun, 18 Sep 2022 08:12:25 +0200 Message-ID: Subject: Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364] To: Mikael Morin Cc: Thomas Koenig , Mikael Morin , gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,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 Sat, Sep 17, 2022 at 9:33 PM Mikael Morin wrote= : > > Le 17/09/2022 =C3=A0 19:03, Thomas Koenig via Fortran a =C3=A9crit : > > > > 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-gbd810d637041dba49a5aca3d085504575374ac6= f. > >> This removal allows more expressions than just array elements, > >> components and complex parts, but the other expressions are excluded b= y > >> 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 the= re > >> was no subreference. > > > > First, thanks a lot for digging into this subject. I have looked throug= h > > 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. 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. Richard. > > So, > > > > integer, dimension(3) :: a > > > > a(1) =3D 1 > > a(3) =3D 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 >