From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91170 invoked by alias); 18 Jan 2017 17:20:30 -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 91155 invoked by uid 89); 18 Jan 2017 17:20:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,RCVD_IN_SORBS_WEB,SPF_PASS autolearn=no version=3.3.2 spammy=PE, Didnt, Didn't, retrieved X-HELO: mout.gmx.net Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.15.18) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 18 Jan 2017 17:20:19 +0000 Received: from vepi2 ([84.63.213.96]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LpcBS-1cwvjb44uM-00fRaM; Wed, 18 Jan 2017 18:20:10 +0100 Date: Wed, 18 Jan 2017 17:20:00 -0000 From: Andre Vehreschild To: Damian Rouson Cc: gfortran , Paul Richard Thomas , Gerald Jerry DeLisle , Alessandro Fanfarillo Subject: Re: [Fortran, Patch] First patch for coarray FAILED IMAGES (TS 18508) Message-ID: <20170118182008.3404205d@vepi2> In-Reply-To: References: <1474481042.70029.ezmlm@gcc.gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-UI-Out-Filterresults: notjunk:1;V01:K0:LD26T4byXj4=:Wzdm4Qe/zg/ggRc4eQ746X zPwd5DrghVzhqaz9qri6zvZXOn//VYuie4aiovVKduzVeDTl2/v2RBR0+UVL3xImo/cMha02q QT1QFnAKyLBZP9Jpb0hVu1cJi5fS1Gu0RMqr6FbagDoaQFt5vnAFLovIXWcjjC6eoDt/x7aYs mW5vsbCPzUnLByEcD84WZk0iMCt9l9CdDXOlEJQZEQ7mUiRmbHJqv76mxGR0eZtgymchtj/AD slr7Nvy0qdQYvT/5hS4suVXCWEy7yOBHwhjj1hg2waeRCoHQ9CReq0XpXe7f0PtE8f7knVbxX FwWtnBh1AZ+Xv8umi0O1LEmtnQXKmDq0mIgwN71+iLUpJg0unEjfaI/liAQukcAqAzxcvSXWA hlo70deNmh17PdvtNCx2piDGHXUf5s6CY6wCAbVPy4cNlhRFs+KKaJv48oVNrHrepaEZf7e/3 BQj6MRT/4tTDzuPZVtfnmPLtu/rW3A8Xc8/z2aG/R9/NTg64OgjEpIgoa+uFXAjVcrEvCHvDE UuIgLFP0nRXiKkMrEISWYfKTBwEh+QKZtGkt1eS7CxT62Ugpc1Ax5omUNSU2i4TtSaWUxgYsW /l7IeJfefG6x7Jjr7cb5zU/tukqU8FPHOHfpDqlbKIWfbrCX9IMDUApTSq/RnfA2Aq9WQ3hDd DSJ063Sn9Zr657HWmj6+8lBloVmX/YMjfkllPe15sexBeGUbh+eCnBOShRZIaa9gAelsPz9Pb 4pYXb8JbTwIaCjFoHKU+b6j0d7mm92/8OZShREZlMML4Q+/KZn9sa8YiaEmP2JufFVWbOlErY gK+wCXD X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg00054.txt.bz2 Hi Damian, the patch you attached showed to be empty in my mail-client. I retrieved it= now from a former mail on the list. It does not apply cleanly anymore. I can't okay it, after looking at some of the lines. There is a function ca= ll declared, but no library function is declared -> link error. Parsing of the arguments to FAIL IMAGE looks dubious to me. There are numerous style violations. The API-documentation has not been updated.=20 So no, I will have to work this over before the patch could have a chance to get accepted. Sorry. Regards, Andre On Tue, 17 Jan 2017 22:39:06 -0800 Damian Rouson wrote: > *PING* >=20 > With the 7.1.0 deadline approaching tomorrow, is there any chance of gett= ing > Alessandro=E2=80=99s FAILED IMAGES patch approved for trunk? As far as I= know, > Fortran is the first internationally standardized language to incorporate > intrinsic support for fault tolerance, which is believed to be essential = to > reaching exaflop performance. As far as I know, gfortran is the first > compiler to implement this Fortran 2015 feature. This is a huge deal and= I=E2=80=99m > hoping Alessandro and I will be able to report that this is a released > feature in a talk we=E2=80=99re giving jointly in early February. Any as= sistance > would be greatly appreciated. >=20 > Damian >=20 > > Begin forwarded message: > >=20 > >=20 > > From: Alessandro Fanfarillo > > Subject: Re: [Fortran, Patch] First patch for coarray FAILED IMAGES (TS > > 18508) Date: September 21, 2016 at 11:03:48 AM PDT > > To: Andre Vehreschild > > Cc: Paul Richard Thomas , gfortran > > , gcc-patches , Mikael Mo= rin > > , Tobias Burnus > >=20 > >=20 > > Thanks Andre. > >=20 > > 2016-09-19 9:55 GMT-06:00 Andre Vehreschild : > >> Hi Alessandro, > >=20 > >> The if in resolve.c at 8837: resolve_failed_image (... is intentional?= It > >> is doing nothing. So do you plan to add more code, or will there never= be > >> anything. If the later I recommend to just put a comment there and rem= ove > >> the empty if. > >=20 > > I added the if statement during the development and I forgot to remove = it. > >=20 > >>=20 > >> There still is no test when -fcoarray=3Dsingle is used. This shouldn't= be so > >> hard, should it? > >=20 > > Done. > >=20 > > Built and regtested on x86_64-pc-linux-gnu. > >=20 > >>=20 > >> Regards, > >> Andre > >>=20 > >> On Mon, 19 Sep 2016 08:30:12 -0700 > >> Alessandro Fanfarillo wrote: > >>=20 > >>> * PING * > >>>=20 > >>> On Sep 7, 2016 3:01 PM, "Alessandro Fanfarillo" > >>> wrote: > >>>=20 > >>>> Dear all, > >>>> the attached patch supports failed images also when -fcoarray=3Dsing= le is > >>>> used. > >>>>=20 > >>>> Built and regtested on x86_64-pc-linux-gnu. > >>>>=20 > >>>> Cheers, > >>>> Alessandro > >>>>=20 > >>>> 2016-08-09 5:22 GMT-06:00 Paul Richard Thomas < > >>>> paul.richard.thomas@gmail.com>: > >>>>> Hi Sandro, > >>>>>=20 > >>>>> As far as I can see, this is OK barring a couple of minor wrinkles = and > >>>>> a question: > >>>>>=20 > >>>>> For coarray_failed_images_err.f90 and coarray_image_status_err.f90 = you > >>>>> have used the option -fdump-tree-original without making use of the > >>>>> tree dump. > >>>>>=20 > >>>>> Mikael asked you to provide an executable test with -fcoarray=3Dsin= gle. > >>>>> Is this not possible for some reason? > >>>>>=20 > >>>>> Otherwise, this is OK for trunk. > >>>>>=20 > >>>>> Thanks for the patch. > >>>>>=20 > >>>>> Paul > >>>>>=20 > >>>>> On 4 August 2016 at 05:07, Alessandro Fanfarillo > >>>>> wrote: > >>>>>> * PING * > >>>>>>=20 > >>>>>> 2016-07-21 13:05 GMT-06:00 Alessandro Fanfarillo < > >>>> fanfarillo.gcc@gmail.com>: > >>>>>>> Dear Mikael and all, > >>>>>>>=20 > >>>>>>> in attachment the new patch, built and regtested on > >>>> x86_64-pc-linux-gnu. > >>>>>>>=20 > >>>>>>> Cheers, > >>>>>>> Alessandro > >>>>>>>=20 > >>>>>>> 2016-07-20 13:17 GMT-06:00 Mikael Morin : > >>>>>>>> Le 20/07/2016 =C3=A0 11:39, Andre Vehreschild a =C3=A9crit : > >>>>>>>>>=20 > >>>>>>>>> Hi Mikael, > >>>>>>>>>=20 > >>>>>>>>>=20 > >>>>>>>>>>> + if(st =3D=3D ST_FAIL_IMAGE) > >>>>>>>>>>> + new_st.op =3D EXEC_FAIL_IMAGE; > >>>>>>>>>>> + else > >>>>>>>>>>> + gcc_unreachable(); > >>>>>>>>>>=20 > >>>>>>>>>> You can use > >>>>>>>>>> gcc_assert (st =3D=3D ST_FAIL_IMAGE); > >>>>>>>>>> foo...; > >>>>>>>>>> instead of > >>>>>>>>>> if (st =3D=3D ST_FAIL_IMAGE) > >>>>>>>>>> foo...; > >>>>>>>>>> else > >>>>>>>>>> gcc_unreachable (); > >>>>>>>>>=20 > >>>>>>>>>=20 > >>>>>>>>> Be careful, this is not 100% identical in the general case. For > >>>>>>>>> older gcc version (gcc < 4008) gcc_assert() is mapped to nothin= g, > >>>>>>>>> esp. not > >>>> to > >>>>>>>>> an abort(), so the behavior can change. But in this case everyt= hing > >>>> is > >>>>>>>>> fine, because the patch is most likely not backported. > >>>>>>>>>=20 > >>>>>>>> Didn't know about this. The difference seems to be very subtle. > >>>>>>>> I don't mind much anyway. The original version can stay if prefe= rred, > >>>> this > >>>>>>>> was just a suggestion. > >>>>>>>>=20 > >>>>>>>> By the way, if the function is inlined in its single caller, the > >>>> assert or > >>>>>>>> unreachable statement can be removed, which avoids choosing betw= een > >>>> them. > >>>>>>>> That's another suggestion. > >>>>>>>>=20 > >>>>>>>>=20 > >>>>>>>>>>> + > >>>>>>>>>>> + return MATCH_YES; > >>>>>>>>>>> + > >>>>>>>>>>> + syntax: > >>>>>>>>>>> + gfc_syntax_error (st); > >>>>>>>>>>> + > >>>>>>>>>>> + return MATCH_ERROR; > >>>>>>>>>>> +} > >>>>>>>>>>> + > >>>>>>>>>>> +match > >>>>>>>>>>> +gfc_match_fail_image (void) > >>>>>>>>>>> +{ > >>>>>>>>>>> + /* if (!gfc_notify_std (GFC_STD_F2008_TS, "FAIL IMAGE stat= ement > >>>>>>>>>>> at %C")) */ > >>>>>>>>>>> + /* return MATCH_ERROR; */ > >>>>>>>>>>> + > >>>>>>>>>>=20 > >>>>>>>>>> Can this be uncommented? > >>>>>>>>>>=20 > >>>>>>>>>>> + return fail_image_statement (ST_FAIL_IMAGE); > >>>>>>>>>>> +} > >>>>>>>>>>>=20 > >>>>>>>>>>> /* Match LOCK/UNLOCK statement. Syntax: > >>>>>>>>>>> LOCK ( lock-variable [ , lock-stat-list ] ) > >>>>>>>>>>> diff --git a/gcc/fortran/trans-intrinsic.c > >>>>>>>>>>> b/gcc/fortran/trans-intrinsic.c index 1aaf4e2..b2f5596 100644 > >>>>>>>>>>> --- a/gcc/fortran/trans-intrinsic.c > >>>>>>>>>>> +++ b/gcc/fortran/trans-intrinsic.c > >>>>>>>>>>> @@ -1647,6 +1647,24 @@ trans_this_image (gfc_se * se, gfc_expr > >>>>>>>>>>> *expr) m, lbound)); > >>>>>>>>>>> } > >>>>>>>>>>>=20 > >>>>>>>>>>> +static void > >>>>>>>>>>> +gfc_conv_intrinsic_image_status (gfc_se *se, gfc_expr *expr) > >>>>>>>>>>> +{ > >>>>>>>>>>> + unsigned int num_args; > >>>>>>>>>>> + tree *args,tmp; > >>>>>>>>>>> + > >>>>>>>>>>> + num_args =3D gfc_intrinsic_argument_list_length (expr); > >>>>>>>>>>> + args =3D XALLOCAVEC (tree, num_args); > >>>>>>>>>>> + > >>>>>>>>>>> + gfc_conv_intrinsic_function_args (se, expr, args, num_args= ); > >>>>>>>>>>> + > >>>>>>>>>>> + if (flag_coarray =3D=3D GFC_FCOARRAY_LIB) > >>>>>>>>>>> + { > >>>>>>>>>>=20 > >>>>>>>>>> Can everything be put under the if? > >>>>>>>>>> Does it work with -fcoarray=3Dsingle? > >>>>>>>>>=20 > >>>>>>>>>=20 > >>>>>>>>> IMO coarray=3Dsingle should not generate code here, therefore p= utting > >>>>>>>>> everything under the if should to fine. > >>>>>>>>>=20 > >>>>>>>> My point was more avoiding generating code for the arguments if = they > >>>> are not > >>>>>>>> used in the end. > >>>>>>>> Regarding the -fcoarray=3Dsingle case, the function returns a re= sult, > >>>> which > >>>>>>>> can be used in an expression, so I don't think it will work with= out > >>>> at least > >>>>>>>> hardcoding a fixed value as result in that case. > >>>>>>>> But even that wouldn't be enough, as the function wouldn't work > >>>> consistently > >>>>>>>> with the fail image statement. > >>>>>>>>=20 > >>>>>>>>> Sorry for the comments ... > >>>>>>>>>=20 > >>>>>>>> Comments are welcome here, as far as I know. ;-) > >>>>>>>>=20 > >>>>>>>> Mikael > >>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>> -- > >>>>> The difference between genius and stupidity is; genius has its limi= ts. > >>>>>=20 > >>>>> Albert Einstein > >>>>=20 > >>=20 > >>=20 > >> -- > >> Andre Vehreschild * Email: vehre ad gmx dot de > >=20 > >=20 >=20 > ________________________________ > Damian Rouson, Ph.D., P.E. > President, Sourcery Institute > http://www.sourceryinstitute.org > +1-510-600-2992 (mobile) >=20 --=20 Andre Vehreschild * Email: vehre ad gmx dot de=20