Date: Thu, 26 Feb 2009 23:26:37 +0100 From: Christoph Mallon <christoph.mallon@gmx.de> To: Christoph Mallon <christoph.mallon@gmx.de>, Ed Schouten <ed@80386.nl>, hackers@FreeBSD.ORG Subject: Re: Renaming all symbols in libmp(3) Message-ID: <49A7171D.1060401@gmx.de> In-Reply-To: <20090226221403.GA96580@zim.MIT.EDU> References: <20090226180756.GX19161@hoeg.nl> <20090226204243.GA96251@zim.MIT.EDU> <49A70092.6030601@gmx.de> <20090226221403.GA96580@zim.MIT.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49A7171D.1060401>