From owner-svn-src-head@FreeBSD.ORG Fri Jul 12 08:07:01 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 09EB09E3; Fri, 12 Jul 2013 08:07:01 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 548921331; Fri, 12 Jul 2013 08:07:00 +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 mail104.syd.optusnet.com.au (Postfix) with ESMTPS id C32B64224C6; Fri, 12 Jul 2013 18:06:48 +1000 (EST) Date: Fri, 12 Jul 2013 18:06:47 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: David Chisnall Subject: Re: svn commit: r253215 - head/lib/msun/src In-Reply-To: <7D521907-4802-4141-9A5E-40EB157A5AEF@FreeBSD.org> Message-ID: <20130712173951.R5131@besplex.bde.org> References: <201307111741.r6BHf5gQ060844@svn.freebsd.org> <51DEFEF7.4080709@coosemans.org> <7D521907-4802-4141-9A5E-40EB157A5AEF@FreeBSD.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=K8x6hFqI c=1 sm=1 a=hIML2bcmzLYA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=Aet6fyW9sl8A:10 a=YqRfAJJkAAAA:8 a=dE5sqkZ3J7ntajQaAuMA:9 a=CjuIK1q_8ugA:10 a=UIDpq6-GphUA:10 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, Tijl Coosemans , src-committers@FreeBSD.org 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 08:07:01 -0000 On Thu, 11 Jul 2013, David Chisnall wrote: > On 11 Jul 2013, at 19:52, Tijl Coosemans 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