From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp08.smtpout.orange.fr [80.12.242.130]) by sourceware.org (Postfix) with ESMTPS id 00C3E3855178 for ; Sun, 18 Sep 2022 09:10:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 00C3E3855178 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 ZqJvoEAcV09yuZqK1oeUG5; Sun, 18 Sep 2022 11:10:42 +0200 X-ME-Helo: [192.168.1.17] X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Sun, 18 Sep 2022 11:10:42 +0200 X-ME-IP: 86.215.174.255 Message-ID: Date: Sun, 18 Sep 2022 11:10:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364] To: Richard Biener Cc: 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> <3edab734-f5bb-5557-ff98-b0ce47d7c510@orange.fr> Content-Language: en-US From: Mikael Morin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: 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. It is unfortunate as there is some desirable behavior within reach here. The test shows that the patch permits the elimination of a useless store. And IL verification doesn't seem that upset with it by the way. Does *(&a[1]) count as a pointer dereference? Even in the original dump it is already simplified to a straight a[1].