From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 26 22:11:54 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 AB66E1065672 for ; Thu, 26 Feb 2009 22:11:54 +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 50BCB8FC14 for ; Thu, 26 Feb 2009 22:11:54 +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 n1QME3Zx096867; Thu, 26 Feb 2009 17:14:03 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n1QME3SM096866; Thu, 26 Feb 2009 17:14:03 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Thu, 26 Feb 2009 17:14:03 -0500 From: David Schultz To: Christoph Mallon Message-ID: <20090226221403.GA96580@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49A70092.6030601@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: Thu, 26 Feb 2009 22:11:55 -0000 On Thu, Feb 26, 2009, Christoph Mallon wrote: > David Schultz schrieb: > >On Thu, Feb 26, 2009, Ed Schouten wrote: > >>One of the reasons why we can't compile the base system yet, is because > >>some applications in the base system (keyserv, newkey, chkey, libtelnet) > >>won't compile, because a library they depend (libmp)on has a function > >>called pow(). By default, LLVM has a built-in prototype of pow(), > >>similar to GCC. Unlike GCC, LLVM raises a compiler error by default. The > >>manual page also mentions this issue. > > > >I think most apps that used to use libmp have transitioned to > >libgmp, so I don't have much of an opinion on this change... > > > >However, if the compiler as a builtin for the math.h-style pow() > >function, and the builtin causes it to choke even when math.h > >isn't #included, that's a bug in the compiler. The people who are > >proposing that we make the base system LLVM-compatible should be > >more forceful in insisting that LLVM be fixed. ;-) What do the LLVM > >folks propose to do about all the (perfectly legal) programs out > >there that have a variable called 'exp'? > > No, it's invalid code to have a function named pow() in a hosted > environment which is not /The/ pow(). > Having a *local* variable named exp is fine, because this declaration > shadows the function. A *global* variable on the other hand is not allowed. The C standard makes no guarantees because it doesn't want to say much about system libraries or how apps are actually linked, but in practice people have found it very useful to do things like link against libraries with special debugging versions of malloc(), and in the past, developers have tried to ensure that this continues to work. (You can find some old threads in the archives.) Of course, people who do this need to take adequate precautions (e.g., linking their programs in the right order, using weak symbols where appropriate), but it does work, and it would be nice if the compiler didn't break it. 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 ;-)