From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42700 invoked by alias); 8 Apr 2018 17:23:54 -0000 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 Received: (qmail 42681 invoked by uid 89); 8 Apr 2018 17:23:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=february, February, jerry, Jerry X-Spam-User: qpsmtpd, 2 recipients X-HELO: mout.gmx.net Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.17.20) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 08 Apr 2018 17:23:52 +0000 Received: from vepi2 ([92.76.207.188]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M8qOm-1fCyKt3odA-00C8XB; Sun, 08 Apr 2018 19:23:48 +0200 Date: Sun, 08 Apr 2018 17:23:00 -0000 From: Andre Vehreschild To: Damian Rouson Cc: GCC-Patches-ML , GCC-Fortran-ML Subject: Re: [Fortran, PATCH, coarray, v1] Extend caf_*_by_ref () API by a type specifier Message-ID: <20180408192346.09318b59@vepi2> In-Reply-To: References: <20180218163900.095f4a86@vepi2> <20180218180728.22b3d954@vepi2> <20180218183307.664b5df1@vepi2> <20180219183153.2299e6d1@vepi2> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-UI-Out-Filterresults: notjunk:1;V01:K0:5UhdVaDNUrM=:7JcDGq317J2s4Cu08P4e57 qj2fKITTRKoNthLumJFkIl3+se4SmafNR/AOCbaWmVT75GKgPytXHD5uFzFOqVUES6pMsV6p/ 6mHasWHeoGTX3dAFQldvaGfqaSWr/NzVE/PIbdixiSrRNna7c+1fZg4QgEdCRRVA/V9keD+g5 ZpODo9dFA6lzw9Q0cUVr9weKcXTXvDGBOtFLhgyNTEY4oV9+SACmNtrf7GR8QiWyeELpB4aTB aCLv2SlaM77joYEUyBzq//0+XDe8TOE/uW/92PIAUVHxyt9sGfbZWqkx03Oe84HMBV06ojhUd leuHByqZtHjfBM8LO2FzmeI857anFJqIQdYBPCrkgG6zAagfK90sneJRA/HiWbYLZ+tuLLQrp Ud1QLXU4Fnmpq/Eni/7m1jQbrHEQPxia7ncegFmP+xBSo/6Sg4niE7hlZM49xr4/S7hufjJ4s pm7lZ+N2yxiJNAMJwXC5jL5RQ18BjYUbPwgw9BdqUDV8XYEgc9098I2ec9QPWgsZXBDICKCrc 8cUZ/xBp68644owl/LidFV87XDgrheyik1DimqPgaxnN+dvSOslhScpaKKIXj8Z/ey+f8ExNP epoDuN/BW7ubWd9D2zbk4MfrpTtY7nVrqwmKZTr9Ch7eWxIzryvY4/obkMQ/TrP4jIPTjc5GR uMAP1DRBMhU60cE9HOXiA6G+Ylejko3vOvPEY9f3hg3olJM+24qMPDPujcilyAJg5GWsZWry1 xrbfi2qc07zRtORXNpzDiQjEbUuMOKOevji5mG9QbVAHijecX8fno9GXPwj7msWMWSKrlXjA6 xNV5zAwMWkltFHQcGdyvvEX69nMGGLhVfoulK1nOxaVc4Td7PI= X-SW-Source: 2018-04/txt/msg00375.txt.bz2 Whoops, hi Damian, sorry for my late reply. I just saw your mail. I am still hanging ~2000 Fortran-Mailinglist mails back and because you copied the mailing list, your mail got filtered to the mailing list folder and I didn't see it in the vast number or unread mails. > Thanks for your latest work on CAF features. =C2=A0Could you let us know = whether > this commit should be tested against the OpenCoarrays master branch or > another branch? =C2=A0With the master branch, I get one test failure (not= counting > two known teams failures that are actually false negatives that I need to > fix): >=20 > lib_caf_mpi::sendget_by_ref(): Warning ! sendget_by_ref() is mostly > unfunctional due to a design error. Split up your statement with coarray = refs > on both sides of the assignment when the datatype transfered is non > 4-byte-integer compatible. libcaf_mpi RUNTIME ERROR: Cannot convert type 1 > kind 4 to type 0 kind 4 >=20 > Is the above expected? =C2=A0Also, because the message comes from sendget= , does > that mean it only affects lines that involve three images such as the > following: >=20 > if (this_image()=3D=3D1) x[2] =3D x[3] You may test this patch against OpenCoarrays, but without having OC patched= it will not benefit from it. I prepared the gfortran patch to fix exactly the above error, but haven't had the time to fix Opencoarrays, too. I'd rather = get a better gfortran-8 up and therefore am trying to get pr81773 and 83606 fix= ed and get them merged into gfortran-8. I follow this strategy, because gcc release cycles are less flexible then O= Cs. So as soon as I get 81773 and 83606 fixed, I will come back to OC fixing the type issues. Sorry for the delayed response. My time is very limited and this last gfort= ran fix involved the scalarizer which is a very complicated concept in the gfor= tran and I haven't worked with before, therefore a steep learning curve. I hope = to be on track more often soon. - Andre >=20 >=20 > Damian >=20 > On February 19, 2018 at 9:32:06 AM, Andre Vehreschild (vehre@gmx.de) wrot= e: >=20 > Hi all,=20=20 >=20 > no objections received therefore committed as r257813. Thanks for fast > review Jerry.=20=20 >=20 > - Andre=20=20 >=20 > On Sun, 18 Feb 2018 18:33:07 +0100=20=20 > Andre Vehreschild wrote:=20=20 >=20 > > Well, after discussing on IRC whether RM should be bothered, I was asked > > to simplify release managers lives and propose, that if no one objects > > within one day, I will merge the patch. So any objections?=20=20 > >=20=20 > > - Andre=20=20 > >=20=20 > > On Sun, 18 Feb 2018 18:07:28 +0100=20=20 > > Andre Vehreschild wrote:=20=20 > >=20=20=20=20 > > > Dear release managers,=20=20 > > >=20=20 > > > this patch (for reference=20=20 > > > https://gcc.gnu.org/ml/fortran/2018-02/msg00124.html) fixes a regress= ion > > > in the coarray api by extending three relatively new functions with o= ne > > > or two arguments, respectively. The patch has been approved by gfortr= an > > > devs. Asking your approval to merge it: Ok to merge to trunk?=20=20 > > >=20=20 > > > Regards,=20=20 > > > Andre=20=20 > > >=20=20 > > > On Sun, 18 Feb 2018 08:53:41 -0800=20=20 > > > Jerry DeLisle wrote:=20=20 > > >=20=20=20=20 > > > > On 02/18/2018 07:39 AM, Andre Vehreschild wrote:=20=20=20=20 > > > > > Hi all,=20=20 > > > > >=20=20 > > > > > attached patch fixes an issue with the coarray API. When a compon= ent > > > > > of a derived type coarray was referenced using a caf_*_by_ref () > > > > > function and that component was not an array with a descriptor, t= hen > > > > > the type of the component was not known. Which additionally meant, > > > > > that type conversion was not applied as required. This patch fixes > > > > > that issue by adding type specifiers to the three caf_*_by_ref-ca= lls > > > > > and implements the functionality for libcaf_single. This is harml= ess > > > > > because other coarray libraries that do not expect this argument = just > > > > > ignore it. Additionally does this patch also provide the first > > > > > working version of caf_sendget_by_ref in libcaf_single, which > > > > > previously only lead to a stack corruption and was not usable sin= ce > > > > > the array descriptor rework (nice job, btw).=20=20 > > > > >=20=20 > > > > > I would like to have this patch in trunk knowing that I am somewh= at=20=20 > > > > > late, but it would be quite necessary, because as it is now, the= =20=20 > > > > > coarray feature for derived types is hardly usable. Furthermore do > > > > > some people name this a regression, because the caf_*_by_ref are = also > > > > > used when the lhs of a caf_get_by_ref() is allocatable which now = does > > > > > not work as expected anymore but before gcc-6 using caf_get() (w/= o=20=20 > > > > > reallocation) did.=20=20 > > > > >=20=20 > > > > > Bootstrapped and regtested ok on x86_64-linux/f27. Ok for trunk?= =20=20 > > > > >=20=20 > > > > > - Andre=20=20 > > > > >=20=20=20=20 > > > >=20=20 > > > > This is OK from the Fortranners perspective. Should touch base with= =20=20 > > > > release manager. It looks harmless though it changes coarray API, > > > > which is hidden behind -fcoarray=3D=20=20 > > > >=20=20 > > > > Regards,=20=20 > > > >=20=20 > > > > Jerry=20=20=20=20 > > >=20=20 > > >=20=20=20=20 > >=20=20 > >=20=20=20=20 >=20 >=20 > --=20=20 > Andre Vehreschild * Email: vehre ad gmx dot de=20=20 --=20 Andre Vehreschild * Email: vehre ad gmx dot de=20