From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 92250 invoked by alias); 17 May 2016 03:30:39 -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 92214 invoked by uid 89); 17 May 2016 03:30:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=D*sfr.fr, HTo:U*mikael.morin, Morin, morin X-HELO: mail-io0-f181.google.com Received: from mail-io0-f181.google.com (HELO mail-io0-f181.google.com) (209.85.223.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 17 May 2016 03:30:23 +0000 Received: by mail-io0-f181.google.com with SMTP id d62so7838263iof.2 for ; Mon, 16 May 2016 20:30:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=7Nzp4G9Oufmmo5RtvJAnJahqfExhuOWIKW723HrIdds=; b=d5VCdc7CHodeBsbR7PZft5bJF9sFJtQnahOwa/gGt4vEM8Lu7fCRlWclkHA6QZnA0X X0AQoDYM+2pSYzugzApSpPRIAmOBACId5ci4TAp88HG7eLW4jedQngteEenkbDtbG+eQ IiwX2o8I88ma/Rg70yWySK6kssdDT6y6LA6dS5nQ7MtweZY8YsKK4HAX6x8G84/hvz7s B3/rLa57p4eGk925FZoA8v+KDdlwhl2cIiybZn6dYUyLqRHheXfZVm+Ggi2fNm3qMDTT 2FqADCGkbmLdBPMErAW7VWkR6fyerEOxAPOrP2p9INJynT5jYjwVe/xVqUk6cBaDTM6G lO7w== X-Gm-Message-State: AOPr4FUoF4qemDZwXRZuEMyrVUNKXvFRQJFrUIkhX3QZJLqXhjA3OGUHMeDX+vOHkHh1MfSUVcOv6NTBMCLT+A== MIME-Version: 1.0 X-Received: by 10.107.27.78 with SMTP id b75mr15400012iob.163.1463455815553; Mon, 16 May 2016 20:30:15 -0700 (PDT) Received: by 10.107.131.221 with HTTP; Mon, 16 May 2016 20:30:15 -0700 (PDT) In-Reply-To: <573A283B.6060306@sfr.fr> References: <573A283B.6060306@sfr.fr> Date: Tue, 17 May 2016 03:30:00 -0000 Message-ID: Subject: Re: [Fortran] Help with intrinsic function returning array From: Alessandro Fanfarillo To: Mikael Morin Cc: gfortran Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-05/txt/msg00041.txt.bz2 Hi, actually I've already tried that way but the size of the array returned by the function cannot be computed by the compiler. The number of failed images is an information contained in OpenCoarrays (which is an external library). Here is an example: program fail integer, allocatable :: failed(:) failed =3D failed_images() end program In this case I expect to see the assignment translated into something like: failed.data =3D _gfortran_caf_failed_images(&size,0B,0B); failed.offset =3D -1; failed.dim[0].lbound =3D 1; failed.dim[0].ubound =3D size; 2016-05-16 14:06 GMT-06:00 Mikael Morin : > Le 11/05/2016 23:35, Alessandro Fanfarillo a =C3=A9crit : >> >> Dear all, >> >> I'm encountering some difficulties with implementing the intrinsic >> function "failed_images" defined in the latest TS-18508 >> >> (http://isotc.iso.org/livelink/livelink?func=3Dll&objId=3D17288706&objAc= tion=3DOpen). >> >> The idea is to call the external _gfortran_caf_failed_images function >> (implemented in OpenCoarrays) than returns a rank-1 integer array >> representing the list of coarray images that have been failed >> (detected by the calling images). >> Of course, the number of failed images is not known a-priori by the >> user, thus the list should be stored in an allocatable array. >> >> So far, I pass by reference the variable representing the list length >> to the _gfortran_caf_failed_images function; once returned, this value >> contains the number of elements composing the array. >> Then, I manually build a temporary array, setting the right >> bounds,type,data and offset. >> >> What I would like to do is to assign this temporary array to the >> variable on the lhs of the assignment. >> >> I noticed several routines that manage the situation of a function >> returning an array but it is not clear to me how to adapt them to my >> situation. >> >> In attachment you can find what I've done so far; the function that >> I'm referring to is gfc_conv_intrinsic_failed_images. >> >> Thanks in advance for your support. >> >> Regards, >> >> Alessandro >> > Hello, > > is there something preventing you from passing the variable's array > descriptor address directly to the function, so that it's already all set= up > and assigned upon return? > I think that would be the easiest. Namely add the GFC_ISYM_FAILED_IMAGES = to > gfc_is_intrinsic_libcall, and see whether it works automatically (no > promise). > > Mikael >