Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 27 Feb 2012 22:02:53 +0100
From: Szabolcs Nagy <>
Subject: Re: libm

* Rich Felker <> [2012-01-23 12:07:15 -0500]:
> On Mon, Jan 23, 2012 at 05:41:52PM +0100, Szabolcs Nagy wrote:
> > i've looked into libm implementations
> > to figure out what's best for musl
> > the extended precision algorithms are reused across
> Any ideas how the different ones evolved (separately written or common
> ancestor code, etc.) and where we should look to pull code from?

meanwhile i looked more into libm design issues

here are some questions i come up with:
for background issues see

Code organization:
(ldX is X bit long double)

Do we want ld128?
Should we try to use common code for ld80 and ld128?
How to do ld64: wrap double functions or alias them?
How to tie the ld* code to the arch in the build system?
Make complex optional?
Keep complex in math/ or cmath/?


Use STDC pragmas (eventhough gcc does not support them)?
Use volatile consistently to avoid evaluation precision and const folding issues?
Use special compiler flags against unwanted optimization (-frounding-math, -ffloat-store)?
Do inline/macro optimization for small functions? (isnan, isinf, signbit, creal, cimag,..)
In complex code prefer creal(), cimag() or a union to (un)pack re,im?

Code cleanups:

Keep diffability with freebsd/openbsd code or reformat the code for clarity?
Keep e_, s_, k_ fdlibm source file name prefixes?
Should 0x1p0 float format be preferred over decimal format?
Should isnan, signbit,.. be preferred over inplace bithacks?
Is unpacking a double into 2 int32_t ok (signed int representation)?
Is unpacking the mantissa of ld80 into an int64_t ok?

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.