cvs commit: src/usr.sbin/route6d route6d.c

[David Schultz]

On Mon, Aug 18, 2003, Dag-Erling Smrgrav wrote:
> Kris Kennaway <kris at obsecurity.org> writes:
> > On Mon, Aug 18, 2003 at 10:23:27AM +0200, Dag-Erling Sm?rgrav wrote:
> > > I have patches which allow world to build successfully with
> > > -fno-builtin...
> > What did you do about the libstdc++ breakage (some symbols are
> > undefined by our tree and only provided by gcc's builtins), or did
> > someone else fix that?
> 
> I implemented fabsl(3), which is what libstdc++ complained about.  We
> could also get by simply by adding
> 
> #ifdef __GNUC__
> #define fabsl(x) __builtin_fabsl(x)
> #endif
> 
> to src/lib/msun/src/math.h.
> 
> I tried to raise interest on the -standards list a few months ago for
> implementing the "long double" versions of the standard math routines,
> as mandated by C99 and SUSv3, but nobody took my bait.  I also managed
> to trash the partial implementation I did have, so all I have right
> now is fabsl(3).

I have implementations of a few of the long double math functions
lying around.  fabsl(3) should be as simple as:

	#include "fpmath.h"
	
	long double
	fabsl(long double e)
	{
		union IEEEl2bits u;
	
		u.e = e;
		u.bits.sign = 0;
		return (u.e);
	}

However, it would be *much* faster if implemented in assembly, and
slightly faster than that as a builtin.  I've been holding off on
working on this until I can figure out a good way to add MI
support in such a way that an MD version would override, if
present.  That way, we could support long double floating point
efficiently on most architectures without hampering porting efforts.
Any suggestions?