From owner-svn-src-head@FreeBSD.ORG Fri Jul 12 09:14:52 2013 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CEC4F675; Fri, 12 Jul 2013 09:14:52 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id 844711884; Fri, 12 Jul 2013 09:14:51 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id BE5E6D40A7B; Fri, 12 Jul 2013 19:14:39 +1000 (EST) Date: Fri, 12 Jul 2013 19:14:39 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Tijl Coosemans Subject: Re: svn commit: r253215 - head/lib/msun/src In-Reply-To: <51DF14F9.50001@coosemans.org> Message-ID: <20130712180753.E5131@besplex.bde.org> References: <201307111741.r6BHf5gQ060844@svn.freebsd.org> <51DEFEF7.4080709@coosemans.org> <7D521907-4802-4141-9A5E-40EB157A5AEF@FreeBSD.org> <51DF0FA5.4050106@coosemans.org> <51DF14F9.50001@coosemans.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=Q6eKePKa c=1 sm=1 a=hIML2bcmzLYA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=Aet6fyW9sl8A:10 a=YqRfAJJkAAAA:8 a=XDH_4B7L22ftifMYl1UA:9 a=CjuIK1q_8ugA:10 a=UIDpq6-GphUA:10 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, David Chisnall , Bruce Evans X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 09:14:52 -0000 On Thu, 11 Jul 2013, Tijl Coosemans wrote: > On 2013-07-11 22:03, Tijl Coosemans wrote: >> On 2013-07-11 21:36, David Chisnall wrote: >>> On 11 Jul 2013, at 19:52, Tijl Coosemans wrote: >>>>> @@ -227,8 +250,6 @@ double expm1(double); >>>>> double fma(double, double, double); >>>>> double hypot(double, double); >>>>> int ilogb(double) __pure2; >>>>> -int (isinf)(double) __pure2; >>>>> -int (isnan)(double) __pure2; >>>> >>>> I think they should stay for the C90 case. >>> >>> That would completely defeat the point of this entire exercise and be >>> redundant unless we aim to support a compiler that only supports C90 >>> and no GNU extensions, in which case you'll hit errors in cdefs.h, >>> long before you get to this point in an include. >> >> isnan(double) is part of SUSv2. It should be visible when compiling with >> -D_XOPEN_SOURCE=500. I think you need something like this: >> #if (__BSD_VISIBLE || __XSI_VISIBLE <= 500) && __ISO_C_VISIBLE < 1999 >> int isinf(double) __pure2; >> int isnan(double) __pure2; >> #endif > > Actually this: > > #if (__BSD_VISIBLE || (defined(__XSI_VISIBLE) && __XSI_VISIBLE <= 500)) && __ISO_C_VISIBLE < 1999 Remove the __ISO_C_VISIBLE part, since this is not in C90. This also fixes a style bug (long line). How can that work? Even you forgot to restore the parentheses around the functions, so the above has syntax errors. Applications would have to use parentheses to get the functions (or not include , but then it doesn't matther if it doesn't declare the functions). Applications that forget to do this will get the macros instead of the functions. If the arg type is double, then the macro will work the same as the functions. Otherwise, it has different semantics, but usually the same result except for signaling NaNs. But does old XSI really specify that parentheses must be used to get isnan() (or can be used to get an isnan() function that is specified to exist)? Old BSD has almost no specification for isnan(), and there probably isn't much old BSD code that carefully prevents use of the macro using parentheses. isnan()'s man page actually says that 3BSD introduced isinf() and isnan() functions, but these have been superseded by the macros. I noticed some more problems in the implementation of these macros and others: - many or all of the __pure2's in the prototypes are wrong, since even the classification functions can have side effects for signaling NaNs. It is impossible to avoid these side effects for extern functions in some cases, since the ABI gives them. I think static inline functions must have the same results as extern functions, so compilers should pessimize inline functions as necessary to get the same bad results, but compilers don't do that. - classification functions are specified to convert to the semantic type (remove any extra precision or exponent range) before classifying. For example, if x is a double slightly larger than sqrt(DBL_MAX), and if double expressions are evaluated in extra exponent range, then x*x is finite with the extra range but infinite in the semantic type. So isinf(x*x) is true, and the implementation #define isinf(x) (fabs(x) == INFINITY) is invalid. clang on x86 gets __builtin_isinf(x*x) this right as a side effect of its pessimization of fabs() to non-inline -- parameter passing to the extern fabs() converts to the semantic type. Sometimes the arg is known not to have extra range, so no conversion is needed. isnan(x) can safely skip the conversion, at least on x86, since conversion doesn't change the classification of NaNs. __builtin_isnan(x*x) for clang on x86 skips the conversion. __builtin_isinfinite(x*x) for clang on x86 is a combination of the above -- isnan() with no conversion and !isinf() with pessimal conversion via non-inline fabs(). I couldn't find any case where a necessary conversion is not done. Our implementation using functions gives the necessary conversions including ones that are broken for signaling NaNs. But there is no problem for with signaling NaNs for expressions like x*x, since the result of an expression with almost any operator in it can't be a signaling NaN. I think C11 has new mistakes for extra precision. It specifies that return reduces to the semantic type, like the classification macros are required to do for their arg. clang -std=c11 doesn't implement this bug for at least: #include double sq(double x) { return (x*x); } double sq2(double x) { return (fabs(x*x); } On i386 without SSE2 (so extra precision), this generates the same code as with -std=c99. Squaring x gives extra precision and exponent range. This is not destroyed on return, so extra precision is not defeated by writing the squaring operation as a function. fabs() is inlined in both cases, so it has little effect here (no effect unless x is NaN), but I think even C99 doesn't permit this. If fabs() were not inline, then the ABI would force destruction of the extra precision and range when it is called, and I think C99 requires conversion to the semantic type for calls. Bruce