From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 26 22:26:40 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 1C71E106566C for ; Thu, 26 Feb 2009 22:26:40 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 7D7C28FC08 for ; Thu, 26 Feb 2009 22:26:39 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 26 Feb 2009 22:26:38 -0000 Received: from p54A3E686.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.230.134] by mail.gmx.net (mp062) with SMTP; 26 Feb 2009 23:26:38 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1/HIElGFYjHuBeubS+Bfm6XDREs76Y+FW7KAywCRR UnXlSyLLUxWmet Message-ID: <49A7171D.1060401@gmx.de> Date: Thu, 26 Feb 2009 23:26:37 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 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> In-Reply-To: <20090226221403.GA96580@zim.MIT.EDU> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 Cc: 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:26:40 -0000 David Schultz schrieb: > 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 The C standard is very explicit which identifiers are reserved, see §7.1.3 > 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 ;-) 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.