Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 4 Mar 2012 01:53:40 -0500
From: Rich Felker <>
Subject: Re: libm

On Sat, Mar 03, 2012 at 11:57:58PM +0100, Szabolcs Nagy wrote:
> see

Some initial questions...

- Why are there two versions (one "slow") of rem_pio2?

- Is __invtrigl.c used? It clashes with the app-reserved namespace.

> i did various useless code formatting cleanups
> as the code was in bad shape (we will have to
> rewrite some parts anyway, so it is not that
> important to keep fdlibm diffability, instead
> i recorded the date of the freebsd and openbsd
> source tree checkout so we can see if they fixed
> something since then)

Sounds fine to me.

> i modified math.h and added complex.h and tgmath.h
> (although i'm not sure about the later, it uses c11)

There's an old gcc way to do tgmath.h without c11, but it's full of
gcc-specific hacks involving __typeof__. If gcc4 allows _Generic even
with -std=c99 etc. then I think _Generic is the best.

> questions:
> keep frexp in stdlib?

It's ok to move it. I had it there from back when there was a separate
libm because printf depends on it.

> how to do the long double ifdefs?

#if LDBL_MANT_DIG == ...

> check x87 fpu precision setting from ld80 code?
> (or we assume it's extended precision)

All existing code (well, mainly macro definitions) in musl assumes its
set to extended, and we provide no code to change it.

> preferred way of handling consts?
> (freebsd code uses 1.0f, (float)1, 0x1p0, static const float one=1;..)
> (i'm not sure why 'one' or 'zero' is used instead of 1 or 0
> maybe it's another compiler float-store bug workaround)
> i assume (float)1.0 is the same as 1f

I like 1.0f, etc. BTW are you sure 1f is valid C? Certainly 1L is not
a valid alternative for 1.0L when you want long double..

> i wonder if it's ok to use a polyeval(coeffs, x) function instead
> of writing out the polynomial (some openbsd long double code uses
> such thing but not everywhere)

I suspect the functions that aren't using it right now depend on a
particular evaluation order to avoid loss of precision. I could be
wrong though; that's just my best guess.

> todo:
> - move the code to musl tree so the changes are recorded there

Very interested in doing this sooner rather than later.

> - fix int32_t issues (there are many)
> - define isnan, signbit, etc macros to be efficient and
> change bithacks into isnan etc in the code when appropriate

Try something like:

union __float_rep { float __x; uint32_t __r; };
#define __FLOAT_REP(x) ((union __float_rep){x}.__r)

#define isnan(x) \
	sizeof(x)==sizeof(float) ? (__FLOAT_REP(x)&0x7fffffff)>0x7f800000 : \
	sizeof(x)==sizeof(double) ? (__DOUBLE_REP(x)&....

Does that work? Of course it would work to just let it get converted
up implicitly to long double and just have one case, but that would be
more expensive I think.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.