From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82648 invoked by alias); 9 Aug 2016 17:44:28 -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 82630 invoked by uid 89); 9 Aug 2016 17:44:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=paul.richard.thomas@gmail.com, paulrichardthomasgmailcom, morinmikaelorangefr, morin-mikael@orange.fr X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-ua0-f174.google.com Received: from mail-ua0-f174.google.com (HELO mail-ua0-f174.google.com) (209.85.217.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 09 Aug 2016 17:44:17 +0000 Received: by mail-ua0-f174.google.com with SMTP id k90so31569802uak.1; Tue, 09 Aug 2016 10:44: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:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=gNkvhV/s0dX5o3JLhlLfas5yMuoqCE1P3lp7QJ4MSiU=; b=jIbyjE20VAuhTFPLgQJIbRPyZnvidZGHZMr7u4XQvMM/zA88spFq/HlrA+h0ugqJyf rRQF5DI06U/i8umFOGH/wZAG8SlQ/dkfyyAqMMW+kr5jYdhLpoQxGu0q+Pzrg3JpLiw8 k9CQBP9zA4UgET9T+fUnHSflt8ikgiwTa6X6Rm5GjzDjjd2owcKUOwEGxrdGjpT06vA5 486oIIObnj5WlnAKbWADiK2Ewp64IMbbc5onU5szT7Lugi3iwaCXBPo5i/KrDBdh/EqB n6+KvIJD/XzKC61bNvA4HAMpdl7odOiNpvr5gYB/FIwLb32IdLMHlkyZKUJ39cox1BHG V31w== X-Gm-Message-State: AEkooutJyORKdT7+QEDIUrGjtI3Ypoo7kIF5YPZ4pHz407UdqfmsrXFge7BgcRRX7kKukGbkxyrrq+BDXay6tA== X-Received: by 10.31.161.16 with SMTP id k16mr4501175vke.122.1470764655129; Tue, 09 Aug 2016 10:44:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.83.110 with HTTP; Tue, 9 Aug 2016 10:44:14 -0700 (PDT) In-Reply-To: References: <20160720113913.24e1f404@vepi2> From: Alessandro Fanfarillo Date: Tue, 09 Aug 2016 17:44:00 -0000 Message-ID: Subject: Re: [Fortran, Patch] First patch for coarray FAILED IMAGES (TS 18508) To: Paul Richard Thomas Cc: Mikael Morin , Andre Vehreschild , gfortran , gcc-patches , Tobias Burnus Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00749.txt.bz2 Thanks Paul, I fixed the unused -fdump-tree-original on the tests. About -fcoarray=3Dsingle, I agree with Andre about not producing code for failed images functions when running in single-image mode. If you, or anybody else, thing otherwise I can adjust the functions to return a constant value (except for fail image... :)). 2016-08-09 5:22 GMT-06:00 Paul Richard Thomas : > Hi Sandro, > > As far as I can see, this is OK barring a couple of minor wrinkles and > a question: > > 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. > > Mikael asked you to provide an executable test with -fcoarray=3Dsingle. > Is this not possible for some reason? > > Otherwise, this is OK for trunk. > > Thanks for the patch. > > Paul > > On 4 August 2016 at 05:07, Alessandro Fanfarillo > wrote: >> * PING * >> >> 2016-07-21 13:05 GMT-06:00 Alessandro Fanfarillo : >>> Dear Mikael and all, >>> >>> in attachment the new patch, built and regtested on x86_64-pc-linux-gnu. >>> >>> Cheers, >>> Alessandro >>> >>> 2016-07-20 13:17 GMT-06:00 Mikael Morin : >>>> Le 20/07/2016 =C3=A0 11:39, Andre Vehreschild a =C3=A9crit : >>>>> >>>>> Hi Mikael, >>>>> >>>>> >>>>>>> + if(st =3D=3D ST_FAIL_IMAGE) >>>>>>> + new_st.op =3D EXEC_FAIL_IMAGE; >>>>>>> + else >>>>>>> + gcc_unreachable(); >>>>>> >>>>>> 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 (); >>>>> >>>>> >>>>> Be careful, this is not 100% identical in the general case. For older >>>>> gcc version (gcc < 4008) gcc_assert() is mapped to nothing, esp. not = to >>>>> an abort(), so the behavior can change. But in this case everything is >>>>> fine, because the patch is most likely not backported. >>>>> >>>> Didn't know about this. The difference seems to be very subtle. >>>> I don't mind much anyway. The original version can stay if preferred, = this >>>> was just a suggestion. >>>> >>>> By the way, if the function is inlined in its single caller, the asser= t or >>>> unreachable statement can be removed, which avoids choosing between th= em. >>>> That's another suggestion. >>>> >>>> >>>>>>> + >>>>>>> + 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 statement >>>>>>> at %C")) */ >>>>>>> + /* return MATCH_ERROR; */ >>>>>>> + >>>>>> >>>>>> Can this be uncommented? >>>>>> >>>>>>> + return fail_image_statement (ST_FAIL_IMAGE); >>>>>>> +} >>>>>>> >>>>>>> /* 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)); >>>>>>> } >>>>>>> >>>>>>> +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) >>>>>>> + { >>>>>> >>>>>> Can everything be put under the if? >>>>>> Does it work with -fcoarray=3Dsingle? >>>>> >>>>> >>>>> IMO coarray=3Dsingle should not generate code here, therefore putting >>>>> everything under the if should to fine. >>>>> >>>> My point was more avoiding generating code for the arguments if they a= re not >>>> used in the end. >>>> Regarding the -fcoarray=3Dsingle case, the function returns a result, = 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 consis= tently >>>> with the fail image statement. >>>> >>>>> Sorry for the comments ... >>>>> >>>> Comments are welcome here, as far as I know. ;-) >>>> >>>> Mikael > > > > -- > The difference between genius and stupidity is; genius has its limits. > > Albert Einstein