From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Sat Feb 21 05:08:48 2015 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 3B1A135880C; Sat, 21 Feb 2015 05:08:48 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from esa2.cray.iphmx.com (esa2.cray.iphmx.com [68.232.143.164]) by www.open-std.org (Postfix) with ESMTP id 3FD0335837E for ; Sat, 21 Feb 2015 05:08:43 +0100 (CET) X-IronPort-AV: E=Sophos;i="5.09,618,1418083200"; d="scan'208";a="475089" Received: from cray-smtp-2.cray.com (HELO CFWEX01.americas.cray.com) ([136.162.34.11]) by esa2.cray.iphmx.com with ESMTP/TLS/AES128-SHA; 21 Feb 2015 04:08:44 +0000 Received: from CFWEX02.americas.cray.com (172.30.74.25) by CFWEX01.americas.cray.com (172.30.88.25) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 20 Feb 2015 22:08:41 -0600 Received: from CFWEX01.americas.cray.com ([169.254.1.190]) by cfwex02.americas.cray.com ([169.254.2.121]) with mapi id 14.03.0224.002; Fri, 20 Feb 2015 22:08:39 -0600 From: Bill Long To: fortran standards email list for J3 CC: WG5 Subject: Re: (j3.2006) (SC22WG5.5452) [ukfortran] Response to TS ballot Thread-Topic: (j3.2006) (SC22WG5.5452) [ukfortran] Response to TS ballot Thread-Index: AQHQTTxygUVTiChB30OKviJUhc9pqpz64kCA Date: Sat, 21 Feb 2015 04:08:39 +0000 Message-ID: References: <20150219231019.EF7E83570D2@www.open-std.org> <20150220114055.4BF3C358556@www.open-std.org> <20150220165455.076C4358262@www.open-std.org> <20150220183834.1CBF735837E@www.open-std.org> In-Reply-To: <20150220183834.1CBF735837E@www.open-std.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.233.140] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-sc22wg5@open-std.org Precedence: bulk On Feb 20, 2015, at 12:38 PM, N.M. Maclaren wrote: > On Feb 20 2015, Bill Long wrote: >>>>=20 >>>> No, for the reasons given in N2038, N2013 and other votes. I need to >>>> reiterate that neither response in N2039 even addresses my comments. = I >>>> believe that incorporating the TS into the main standard will cause >>>> serious harm to Fortran, because the (semantic) difficulties cannot be >>>> resolved (let alone specified unambiguously) in the time available. >>>> Indeed, it is not clear even that they ARE soluble, because this TS is >>>> specifying a feature that is beyond the state of the art, and has been >>>> for half a century. I would be prepared to change my vote to abstain = if >>>> the decision to incorporate it were reversed. >>>>=20 >>>> Response >>>> It is our belief that agreeing to delay to a later revision of the >>>> Fortran standard would lead to several "no" votes. Failure to >>>> standardize a resilience capability before compilers implement F2015 >>>> would lead to vendors implementing incompatible schemes, hurting the >>>> goal of code portability. >>>=20 >>> Whether or not the second statement is true, and it is extremely >>> unclear whether it is, it is not a response to my objections. I am >>> asserting that the task is infeasible, for the reasons I gave. >>=20 >> There are differing opinions on whether "the task is infeasible". I tend= =20 >> to weight higher the opinions of the guys who will end up writing the=20 >> compiler and runtime code. >=20 > Firstly, as I have told you before, I have written run-time systems that > allowed recovery, call back to user code and continuation. I have met > (or even heard of) very, very few other people that have. And, based > on that and experience with projects that have tried to specify such > recovery, I can tell you that writing a run-time system that recovers > when possible is TRIVIAL by comparison to specifying the circumstances > when recovery is possible and the state of the program following such > recovery - let alone doing that in a system-indepdent fashion! >=20 > It is the task that WG5 is faced with that I regard as infeasible, and > (as evidence) point out that it has been an important but unachievable > requirement for half a century. As I hope that we all know, specifying > the syntax for a facility but leaving its semantics unclear does NOT > help portability, as each system behaves differently. For example, > following a failure, exactly WHICH objects are: > Defined > In an unspecified but valid state > Undefined but definable > Undefined and not definable >=20 > Please will you stop misrepresenting me? >=20 Sorry, Nick. I was mistaken in assuming that the =93infeasible=94 task was= the compiler and runtime work. I=92m glad that we have a demonstration of= success in that area.=20 Did you provide documentation with your project? (I=92m guessing so.) Bas= ed on that, any suggestions for our writing task would be most appreciated.= =20 In terms of =93specifying the circumstances when recovery is possible=94, = I see two aspects. One is whether there are syntax and semantics specified= that allow the program to resume execution at a place that is not part of = the normal execution sequence. Second is whether the algorithm is such tha= t it is possible to restart. Our current position is that the second is e= ntirely the programmer=92s responsibility. We only supply help with the fi= rst.=20 The task of =93specifying the state of the program following such recovery= =94 is more of a challenge. It depends on how the programmer is trying to = restart. If, for example, the program includes checkpoints, the desired ac= tion after the END TEAM statement would be to branch to code that restored = state from the most recent checkpoint and resume execution just after that = checkpoint. The method we=92re supplying additional help for is to branch = back to the beginning of the current CHANGE TEAM construct and re-execute i= t. There are a lot of potential states for objects in the program. Paper= 15-138 is an attempt at describing what happens. Suggestions for improvem= ent are welcome. Cheers, Bill >=20 > Regards, > Nick. >=20 > _______________________________________________ > J3 mailing list > J3@mailman.j3-fortran.org > http://mailman.j3-fortran.org/mailman/listinfo/j3 Bill Long = longb@cray.com Fortran Technical Suport & voice: 651-60= 5-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101