From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79527 invoked by alias); 18 Jan 2017 06:42:35 -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 79513 invoked by uid 89); 18 Jan 2017 06:42:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_40,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=genius, U*fortran, fortran@gcc.gnu.org, fortrangccgnuorg X-HELO: smtp106.biz.mail.ne1.yahoo.com Received: from smtp106.biz.mail.ne1.yahoo.com (HELO smtp106.biz.mail.ne1.yahoo.com) (98.138.207.13) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 18 Jan 2017 06:42:23 +0000 Received: (qmail 31539 invoked from network); 18 Jan 2017 06:42:21 -0000 X-Yahoo-SMTP: x0SCrfmswBCvW0SeKOpOOY7IMgY- From: Damian Rouson Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [Fortran, Patch] First patch for coarray FAILED IMAGES (TS 18508) Message-Id: Date: Wed, 18 Jan 2017 06:42:00 -0000 Cc: Paul Richard Thomas , Andre Vehreschild , Gerald Jerry DeLisle , Alessandro Fanfarillo To: gfortran X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg00049.txt.bz2 Resending as plain text: *PING* With the 7.1.0 deadline approaching tomorrow, is there any chance of gettin= g Alessandro=E2=80=99s FAILED IMAGES patch approved for trunk? As far as I= know, Fortran is the first internationally standardized language to incorp= orate intrinsic support for fault tolerance, which is believed to be essent= ial to reaching exaflop performance. As far as I know, gfortran is the fir= st compiler to implement this Fortran 2015 feature. This is a huge deal an= d 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 assistance would be greatly appreciated. Damian > Begin forwarded message: >=20 >=20 > From: Alessandro Fanfarillo > Subject: Re: [Fortran, Patch] First patch for coarray FAILED IMAGES (TS 1= 8508) > Date: September 21, 2016 at 11:03:48 AM PDT > To: Andre Vehreschild > Cc: Paul Richard Thomas , gfortran , gcc-patches , Mikael Morin , 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? I= t 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 remov= e 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 b= e 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=3Dsingle= 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=3Dsingl= e. >>>>> 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 o= lder >>>>>>>>> gcc version (gcc < 4008) gcc_assert() is mapped to nothing, esp. = not >>>> to >>>>>>>>> an abort(), so the behavior can change. But in this case everythi= ng >>>> 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 preferr= ed, >>>> 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 between >>>> 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 statem= ent >>>>>>>>>>> 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 put= ting >>>>>>>>> everything under the if should to fine. >>>>>>>>>=20 >>>>>>>> My point was more avoiding generating code for the arguments if th= ey >>>> are not >>>>>>>> used in the end. >>>>>>>> Regarding the -fcoarray=3Dsingle case, the function returns a resu= lt, >>>> which >>>>>>>> can be used in an expression, so I don't think it will work without >>>> 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 limits. >>>>>=20 >>>>> Albert Einstein >>>>=20 >>=20 >>=20 >> -- >> Andre Vehreschild * Email: vehre ad gmx dot de