From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Mon Jul 29 22:59:09 2019 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 6818F358485; Mon, 29 Jul 2019 22:59:09 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from math.jpl.nasa.gov (unknown [137.79.7.57]) by www.open-std.org (Postfix) with ESMTP id 1BDBC3567F4 for ; Mon, 29 Jul 2019 22:59:08 +0200 (CEST) Received: by math.jpl.nasa.gov (Postfix, from userid 3593) id 9EB8033DA73; Mon, 29 Jul 2019 13:59:07 -0700 (PDT) Subject: Re: [J3] (SC22WG5.6116) [EXTERNAL] Re: [ukfortran] Two things from IFIP WG 2.5 meeting From: Van Snyder To: sc22wg5 In-Reply-To: <7B89CC76-CA0D-413F-BD50-936B47D24347@cray.com> References: <20190726015634.E052D35860C@www.open-std.org> <20190726172038.9A3DD358B76@www.open-std.org> <7B89CC76-CA0D-413F-BD50-936B47D24347@cray.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Jul 2019 13:59:07 -0700 Message-ID: <1564433947.31099.184.camel@math.jpl.nasa.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-37.el6) Sender: owner-sc22wg5@open-std.org Precedence: bulk On Mon, 2019-07-29 at 07:59 +0000, Anton Shterenlikht wrote: >=20 > > On 26 Jul 2019, at 18:20, Van Snyder via J3 = wrote: > >=20 > > Some time during the last twenty or thirty years, I proposed a STRICT > > block, in which calculations would follow strict arithmetic rules. > > I.e., "turn off goofy standard-violating optimizations here, but go > > ahead and use them elsewhere." >=20 > This is currently achievable with all processors I know, via separate > compilation units. > Indeed, in large projects it's virtually inevitable > that different parts of the executable > will be compiled with different optimisation levels. > This is not different from using different kinds in different procedures. > I think no additions to the standard are need to address this use case. Some progress toward strict arithmetic is possible by hiding crucial parts of a computation in procedures, and then expending some (sometimes significant) effort to convince the processor not to subvert your careful work -- which can't always be done. And, of course, it's slower, unless the processor inlines the procedure, which then usually results in subverting your careful work. It also doesn't solve all problems, not least because the standard ubiquitously says "processor-dependent approximation." For example, the KIND argument of the REAL intrinsic with real A argument is frequently ignored within an expression, no matter what optimization level is selected. That was the subject of interp F03/0121. No version of this interp has passed. > Anton >=20