From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80517 invoked by alias); 4 Aug 2016 03:09:21 -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 79543 invoked by uid 89); 4 Aug 2016 03:08:12 -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=20160720, 2016-07-20, andre, Andre X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-ua0-f173.google.com Received: from mail-ua0-f173.google.com (HELO mail-ua0-f173.google.com) (209.85.217.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 04 Aug 2016 03:08:02 +0000 Received: by mail-ua0-f173.google.com with SMTP id 35so166355875uap.1; Wed, 03 Aug 2016 20:08:01 -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=dUEbWoGburjjXMtIjca3TzR8ecWCGtOg2ZXEJdNyg9g=; b=GPLcDiJ0ZegKjsPLO3PR0Hhs/FkuDAQIHxzD/SmHBhykkom22q4a4B+GR+fPpLXfOJ oEUIZojH1w/yrvezMH3diOBOoGPF95qSQGRkLyQ+tmcUjEw0+IpqEgzGUCxWhpTtdDNV 8K1VucGhndnHqsu7yRqzUEvpUDuFGDFduccKdGb5wWkDXsClJe5qh4Q1+sobURKwUktr 1+ZAUukuIazEEvNZ35rAmrdoTVg/SfPK9ktMskkqYB/GbsQCGKj8F3eCCb1qKUBE1xyG iBDSz86YJDEvwtlQsJChfLkty2dCWvp3LQBduqeUd/yw/RgG/P7MpV60INqNUh02tNQr 07vQ== X-Gm-Message-State: AEkoousAD7StTz6PviSBU2bE/GcUB0CJzBC9OthTUgHaQqUj15nIpjOF5NKM0euNZCdi7MCP4PVY+awveH7DkQ== X-Received: by 10.176.67.6 with SMTP id k6mr29557537uak.96.1470280079621; Wed, 03 Aug 2016 20:07:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.83.110 with HTTP; Wed, 3 Aug 2016 20:07:58 -0700 (PDT) In-Reply-To: References: <20160720113913.24e1f404@vepi2> From: Alessandro Fanfarillo Date: Thu, 04 Aug 2016 03:09:00 -0000 Message-ID: Subject: Re: [Fortran, Patch] First patch for coarray FAILED IMAGES (TS 18508) To: Mikael Morin Cc: Andre Vehreschild , gfortran , gcc-patches , Paul Richard Thomas , Tobias Burnus Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00012.txt.bz2 * 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, th= is >> was just a suggestion. >> >> 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. >> >> >>>>> + >>>>> + 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 are= not >> used in the end. >> Regarding the -fcoarray=3Dsingle case, the function returns a result, wh= ich >> can be used in an expression, so I don't think it will work without at l= east >> hardcoding a fixed value as result in that case. >> But even that wouldn't be enough, as the function wouldn't work consiste= ntly >> with the fail image statement. >> >>> Sorry for the comments ... >>> >> Comments are welcome here, as far as I know. ;-) >> >> Mikael