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

[Bruce Evans]

On Thu, 11 Jul 2013, David Chisnall wrote:

> On 11 Jul 2013, at 19:52, Tijl Coosemans <tijl at coosemans.org> wrote:
>
>> GCC doesn't support _Generic yet for -std=c11.
>
> Ugh.  Given that they also lack a fine-grained feature check mechanism, they really should not advertise support for a language dialect if they don't support it.
>>
>>> +#elif __GNUC_PREREQ__(5, 1)
>>
>> GCC 3.1?
>
> Ooops, I changed this to 5.1 to test the other code path and forgot to revert it.
>
>> Last __fpclassifyd should be __fpclassifyl.
>
> Fixed.

There are still many style bugs to fix:
- indentation of continuation lines.  It was changed from the normal 4
   spaces to 1 tab in macro definitions.  The style rule for continuation
   lines for #define's is not as clear as for statements, but math.h used
   to use 4 spaces consistently.
- whitespace before backslashes.  It is neither minimal, maximal, lines
   up the backslashes to tab boundaries, lines up the backslashes across
   macros, nor uses tabs.  It repaces formatting that uses tabs to line
   up all backslashes to the 7th tab stop.
- whitespace before macro bodies.  It was changed from the normal 1 tab
   to 1 space.  The next block of macros (for __MATH_BUILTIN_RELOPS)
   provides examples of normal formatting, and the block beginning with
   isfinite() looks really ugly in comparison.
- verbose names, and resulting ugly formatting to avoid long lines
- the x parameter is missing parentheses in the main macros starting at
   fpclassify().  __fp_type_select() supplies the necessary parentheses,
   but this is fragile.

BTW, is it really permitted for the comparison macros to evaluate their
args more than once?  This is done for the !__MATH_BUILTIN_RELOPS case.
I hoped that you replace all the inlines for isnan() by macros, but
now I can't see how to do this without using either multiple evaluation
of the arg or an unportable statement-expression.  However, the relops
already use macros that are sloppy about multiple evaluation in the
!_MATH_BUILTIN_RELOPS case, so math.h would be no more broken if it did
the same for isnan().  isnan() is just a special relop that is even
simpler than the others, but its implementation is more complicated and
10-20 times larger in math.h alone (100 times larger counting all the
compatibility cruft for it in other files).

>>> @@ -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.

They aren't in C90.  More in another reply.

Bruce