svn commit: r253215 - head/lib/msun/src

[Bruce Evans]

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 <tijl at coosemans.org> 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 <math.h>,
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 <math.h>
 	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