From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5288 invoked by alias); 10 Sep 2015 18:36:23 -0000 Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org Received: (qmail 5265 invoked by uid 89); 10 Sep 2015 18:36:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-ob0-f180.google.com Received: from mail-ob0-f180.google.com (HELO mail-ob0-f180.google.com) (209.85.214.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 10 Sep 2015 18:36:21 +0000 Received: by obqa2 with SMTP id a2so42113252obq.3; Thu, 10 Sep 2015 11:36:20 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.250.195 with SMTP id ze3mr33504612obc.30.1441910179881; Thu, 10 Sep 2015 11:36:19 -0700 (PDT) Received: by 10.202.4.4 with HTTP; Thu, 10 Sep 2015 11:36:19 -0700 (PDT) In-Reply-To: <37777B3C-CD77-4D57-BC69-14F6D0F8D331@gmail.com> References: <37777B3C-CD77-4D57-BC69-14F6D0F8D331@gmail.com> Date: Thu, 10 Sep 2015 18:36:00 -0000 Message-ID: Subject: Re: [Patch, fortran] PR66681 - Wrong result in assigning this_image() to a complex coarray From: Paul Richard Thomas To: FX Cc: "fortran@gcc.gnu.org" , gcc-patches Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00071.txt.bz2 Dear FX, I am puzzled by this business of the SAVE_EXPR: First, I agree entirely that it is a mystery as to why the SAVE_EXPR appears. It does not do so for array elements nor for arrays. Secondly, as far as I can tell, SAVE_EXPR_RESOLVED_P(=E2=80=A6) merely impl= ies that a pointer to a tree is returned. In fact, it does not seem to signify a usless expression since, in one case in trans-decl.c, it is actually used. Third, I do not see where the side effects will appear. Although this is a co-array element, assignment to it is a purely local affair. It has to be explicitly referenced from another process before communication occurs, does it not? This is where my ignorance surfaces in full force, however :-( I don't know what to do with this, other than to dereference a tree pointer if that appears. Ideally, the SAVE_EXPR should be suppressed at source, although I do not know how to accomplish that. I would bemore than happy to act on advice from other maintainers.... Cheers Paul On 8 September 2015 at 23:02, FX wrote: >> This is something of a corner case, where gfc_conv_expr comes back >> with a SAVE_EXPR, in the case of complex, scalar, coarray lvalues. The >> first field of the SAVE_EXPR is a perfectly viable expression to >> assign to, so I have taken that. If anybody out there has a better >> solution, please speak up! > > If the SAVE_EXPR is a useless one, it should have SAVE_EXPR_RESOLVED_P(= =E2=80=A6) be true. Then you can simply discard it as you=E2=80=99re doing. > If not, we need to created a temp variable, as simply removing the SAVE_E= XPR will lead to multiple side-effects evalution in some cases otherwise. > > But I=E2=80=99m curious as to where the SAVE_EXPR is created. As far as I= can tell, all SAVE_EXPR in our front-end are created by explicit calls to = save_expr(), of which there are very few. I don=E2=80=99t see which one is = the culprit here :( But creating a SAVE_EXPR for a LHS is definitely not a= good idea in the first place. > > FX > > --=20 Outside of a dog, a book is a man's best friend. Inside of a dog it's too dark to read. Groucho Marx