From owner-freebsd-numerics@freebsd.org Sat May 13 10:40:43 2017 Return-Path: Delivered-To: freebsd-numerics@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 814C5D696D9 for ; Sat, 13 May 2017 10:40:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 68BAD11B1 for ; Sat, 13 May 2017 10:40:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: by mailman.ysv.freebsd.org (Postfix) id 682CAD696D7; Sat, 13 May 2017 10:40:43 +0000 (UTC) Delivered-To: numerics@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 67D78D696D6 for ; Sat, 13 May 2017 10:40:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-8.reflexion.net [208.70.210.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2CB5311AE for ; Sat, 13 May 2017 10:40:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4544 invoked from network); 13 May 2017 10:40:41 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 13 May 2017 10:40:41 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sat, 13 May 2017 06:40:41 -0400 (EDT) Received: (qmail 18264 invoked from network); 13 May 2017 10:40:40 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 May 2017 10:40:40 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 29F9BEC8697; Sat, 13 May 2017 03:40:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: catrig[fl].c and inexact From: Mark Millard In-Reply-To: <20170513060803.GA84399@troutmask.apl.washington.edu> Date: Sat, 13 May 2017 03:40:39 -0700 Cc: Bruce Evans , freebsd-hackers@freebsd.org, numerics@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170512215654.GA82545@troutmask.apl.washington.edu> <20170513103208.M845@besplex.bde.org> <20170513060803.GA84399@troutmask.apl.washington.edu> To: sgk@troutmask.apl.washington.edu X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 10:40:43 -0000 On 2017-May-12, at 11:08 PM, Steve Kargl wrote: > On Sat, May 13, 2017 at 11:35:49AM +1000, Bruce Evans wrote: >> On Fri, 12 May 2017, Steve Kargl wrote: >>=20 >>> So, I've been making improvements to my implementations of >>> the half-cycle trig functions. In doing so, I decide to >>> add WARNS=3D2 to msun/Makefile. clang 4.0.0 dies with an >>> error about an unused variable in raise_inexact() from >>> catrig[fl].c. >>>=20 >>> /usr/home/kargl/trunk/math/libm/msun/src/catrigl.c:195:2: error: = unused variable >>> 'junk' [-Werror,-Wunused-variable] >>> raise_inexact(); >>> ^ >>> /usr/home/kargl/trunk/math/libm/msun/src/catrigl.c:56:45: note: = expanded from >>> macro 'raise_inexact' >>> #define raise_inexact() do { volatile float junk =3D 1 + tiny; } = while(0) >>> ^ >>> Grepping catrig.o for the variable 'junk' suggests that 'junk' is >>> optimized out (with at least -O2). >>=20 >> Just another bug in clang. Volatile variables cannot be optimized = out >> (if they are accessed). >=20 > Does this depend on scope? 'junk' is local to the do {...} while(0); > construct. Can a compiler completely eliminate a do-nothing scoping > unit? I don't know C well enough to know. I do know what I have > observed in clang. [This note ignores other standards than C99/C11 that might place other constraints. And I've done no checking of compiler results, I've just looked at a couple of the C standards.] Note: I've not looking to tiny's declaration. It may contribute in a way not covered below. Unfortunately the declarator in an init-declarator that has an initializer is not part of an expression. The rules for volatile are tied to uses in expressions, not to the declarator. (Which is a hole in the language definition as far as I can tell.) There is one part of the wording that might mitigate this, tied to a full declarator having a sequence point at its end despite the declarator itself not being an expression, even if its initializer is one. There is another wording detail that might as well. Still, overall it would seem safer to be sure there is an expression that references the volatile object, not having only its declarator. But I would not take even that as a guarantee under the C standards. It may seem a silly difference but: do { volatile float junk=3D1; junk+=3Dtiny; } while(0) may well be a better way of writing the "must evaluate" part of the intent simply because junk is used in an expression. Also it has both read and write access, so is a little more "used". The sequence point before the assignment can help avoid compile-time evaluation as well. Details if you care. . . I used the C99 and C11 definitions here, I reference C11 section numbering but C99 agrees as I remember. 5.1.2.3 Program execution says: "Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment. Evaluation of an expression may produce side effects." Note that raising inexact does not fit in the definition of side effect as far as I can tell. So a compiler need not consider such a thing for side-effect issues if I understand right. [C11 specific wording:] "The presence of a sequence point between the evaluations of expressions A and B implies that every value computation and side effect associated with A is sequenced before every value compuation and side effect associated with B." [C99 is similar but is before the detailed "sequenced before" definition.] "An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including any caused by calling a function or accessing a volatile object)." Can a accessing a volatile object ever be classified as having "no needed side effects"? More on this later. [Remember what "side effect" excludes, as noted earlier. So some consequences need not be considered by the compiler, all in the name of optimizations.] 6.7.3 Type Qualifiers says: "An object that has volatile-qualified type . . . Therefore any expression referring to such as object shall be evaluated strictly according to the rules of the abstract machine, as described in 5.1.2.3. Furthermore, at every sequence point the value last stored in the object shall agree with that prescribed by the abstract machine, except as modified by the unknown factors mentioned previously. What constitutes an access to an object that has volatile-qualified type is implementation-defined." This part is mixed: what the sequence point wording giveth the last sentence taketh away. (More later.) It also says in a note (134): "A volatile declaration may be used to describe an object corresponding to a memory-mapped input/output port or an object accessed by an asynchronously interrupting function. Actions on objects so declared shall, not be "optimized out" by an implementation or reordered except as permitted by the rules for evaluating expressions." Since rules for evaluating expressions are not rules for declarators (vs. initializers), this could be read as not allowing the "optimize out". (But the abstract machine's description is not explicit about declarators for such issues.) The C99 Rationale: The C99 Rationale was explicit about static volatile for a memory mapped I/O register, static const volatile for a memory mapped input port, const volatile and volatile for variables shared across processes. To some extent this identifies examples of contexts with "needed side effects" that have hardware details to take into account. For taking into account hardware details: ". . . Whatever decision are adopted on such issues must be documented, as volatile access is implementation-defined". For volatile use with no explicitly identified hardware details: volatile would appear to be no more than a potential hint for such a context, not an effective requirement. The implementation-defined status could allow lack of access. Overall, based on what I see in the C99 and C11 language definitions, I'd not be willing to declare clang wrong (if it did optimize out junk), even with my alternative formulation. C does not have an explicit Principle of Least Astonishment as a official guideline to its interpretation and the rules are very biased to allowing so-called optimizations. "junk" does not fit with being shared across processes (for example its address is not handed to anything) and is not static or even global. There is no known type of potential context for specific hardware details that would need to be taken into account for junk. That in turn leaves open not accessing it at all as far as I can tell. =3D=3D=3D Mark Millard markmi at dsl-only.net