From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21607 invoked by alias); 16 Jul 2011 16:44:02 -0000 Received: (qmail 21583 invoked by uid 22791); 16 Jul 2011 16:44:00 -0000 X-SWARE-Spam-Status: No, hits=-0.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp22.services.sfr.fr (HELO smtp22.services.sfr.fr) (93.17.128.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 16 Jul 2011 16:43:43 +0000 Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2218.sfr.fr (SMTP Server) with ESMTP id 7EBD0700008C; Sat, 16 Jul 2011 18:43:42 +0200 (CEST) Received: from gimli.local (104.15.72.86.rev.sfr.net [86.72.15.104]) by msfrf2218.sfr.fr (SMTP Server) with ESMTP id 46653700008A; Sat, 16 Jul 2011 18:43:42 +0200 (CEST) X-SFR-UUID: 20110716164342288.46653700008A@msfrf2218.sfr.fr From: Mikael Morin To: fortran@gcc.gnu.org Subject: Re: [Patch, Fortran] Support allocatable *scalar* coarrays Date: Sat, 16 Jul 2011 17:07:00 -0000 User-Agent: KMail/1.13.5 (FreeBSD/8.2-PRERELEASE; KDE/4.5.5; amd64; ; ) Cc: Tobias Burnus , gcc patches References: <4E1A03E8.3050706@net-b.de> <201107161459.26836.mikael.morin@sfr.fr> <4E21AD70.2090508@net-b.de> In-Reply-To: <4E21AD70.2090508@net-b.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201107161843.39951.mikael.morin@sfr.fr> X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-07/txt/msg01331.txt.bz2 On Saturday 16 July 2011 17:25:36 Tobias Burnus wrote: > Mikael Morin wrote: > > let me understand one thing about coarray scalars: despite their name, > > they are arrays, right? > > Yes and no. In terms of the language, they are scalars - but they have a > codimension, e.g. > integer, save :: A[4:6, 7:*] > is a scalar variable on each image, but it has a coarank of 2 with > lcobound(A) == [4, 7] and ucobound(A, dim=1) == 7. ucobound(A, dim=1) == 6 ? Otherwise I'm even more confused. > > Then when you do in gfc_conv_array_ref: > > > > + if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (se->expr))) > > + se->expr = build_fold_indirect_ref (gfc_conv_array_data > > (se->expr)); [...] > > > > return; > > > > you are returning scalar[1] instead of scalar (== scalar[this_image()]) > > or scalar[whatever_image_selector], aren't you? > > Well, the current implementation supports effectively only a single > image - for -fcoarray=single on purpose and for -fcoarray=lib because it > has not yet been implemented. > > Later, one has to add some function call for "scalar[]" > while "scalar" itself is the local variable and can be handled as above. Ah, OK; that's where I was misunderstanding coarrays. I was thinking that a (possibly out of date) copy of remote images was available locally, like a normal array; and with any network exchanges happening during the SYNC* calls only. In fact network traffic happens anywhere there are square brackets, and SYNC* are mere iddle waits, right? > The expression of "scalar" ends up having expr->ref->type == REF_ARRAY > with dimen_type == DIMEN_THIS_IMAGE. That way one can distinguish a > reference to the local coarray and to a remote coarray (coindexed > variable); note that "coarray[this_image()]" also counts as > remote/coindexed. While it seems to work well, we would probably have gained some clarity by using a separate struct for coarray references. For example with the current scheme, array[1,2] has type ARRAY_FULL, but some dimen_type are of type DIMEN_ELEMENT. Odd. > > Sorry for the delay; it seems that the more it goes, the more you are the > > only one who can maintain coarray stuff. :-( > > Well, Daniel Carrera develops into an trans*.c, allocate, > libgfortran/caf/ expert :-) > Thanks for all the clarifications. Patch is OK (I guess). Mikael