From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 27 05:26:11 2009 Return-Path: Delivered-To: hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32765106566C for ; Fri, 27 Feb 2009 05:26:10 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 18C198FC1D for ; Fri, 27 Feb 2009 05:26:09 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n1R5SMYe098812; Fri, 27 Feb 2009 00:28:22 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n1R5SL56098811; Fri, 27 Feb 2009 00:28:21 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Fri, 27 Feb 2009 00:28:21 -0500 From: David Schultz To: Christoph Mallon Message-ID: <20090227052821.GA98527@zim.MIT.EDU> Mail-Followup-To: Christoph Mallon , Ed Schouten , hackers@FreeBSD.ORG References: <20090226180756.GX19161@hoeg.nl> <20090226204243.GA96251@zim.MIT.EDU> <49A70092.6030601@gmx.de> <20090226221403.GA96580@zim.MIT.EDU> <49A7171D.1060401@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49A7171D.1060401@gmx.de> Cc: Ed Schouten , hackers@FreeBSD.ORG Subject: Re: Renaming all symbols in libmp(3) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 05:26:11 -0000 On Thu, Feb 26, 2009, Christoph Mallon wrote: > David Schultz schrieb: > >As for gcc's math builtins, most of them are buggy. They fail to > >respect the dynamic rounding mode, fail to generate exceptions > >where appropriate, fail to respect FENV_ACCESS and other pragmas, > >etc. Also, the complex builtins use simplified formulas that don't > >get the right answers for complex numbers with inf/nan components. > >Try running some of the tests in tools/regression/lib/msun without > >-fno-builtin and see what happens ;-) > > pow() is just an example. > The compiler may do magic with any call which has semantics defined by > the C standard in a hosted environment. Okay, so first, the world doesn't revolve around the strictest possible interpretation of the C standard. For example, FreeBSD has an extension such that `printf("%s", NULL)' prints "(null)" instead of having undefined behavior. But gcc translates this into `puts(NULL)', which once again has undefined behavior. You can put on your lawyer hat and counter that the beloved standard doesn't guarantee that any such thing will work, but that's a very contrarian attitude; the bottom line is that it's a POLA violation, and the extension worked just fine for many years. Second, the problems with the math builtins I cited above violate even a strict interpretation of the C standard. Third, this is a digression, and this is the last I'm going to say about it. :-)