Date: Mon, 5 Mar 2012 09:51:35 +0100 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: libm * Rich Felker <dalias@...ifal.cx> [2012-03-04 13:43:39 -0500]: > On Sun, Mar 04, 2012 at 03:50:41PM +0100, Szabolcs Nagy wrote: > > maybe it should be called __rem_pio2_large ? > > That's better. Not sure what the best name would be.. > renamed > > i wrote it using generic since i couldnt come up with > > any way to solve it in c99 > > There's no way to solve it in C99 matching the return types, but if > you don't care about return types, it's pretty easy (albeit ugly and > verbose) with ?: conditionals based on sizeof(x). > hm i haven't even thought about return types my problem was calling the double version of a function when the arg is integral and the float version when the arg is float. (it can be done with sizeof if we can assume there is a larger integer type than float, but i thought that was ugly) even if we don't care about return types and int arguments it seems tgmath is very ugly > > complex is missing but it is not hard to add > > (if you want to wait for it) > > Either way. > > > the parts i wrote may need some review or testing > > (it can be done after merging of course) > > Yes, I'm okay with that. > i can do the merge and then you git pull or you can do it from libm the long double ifdefs needs to be fixed and math.h sorted out > There's the libc-testsuite git repo, and then cluts. Neither is > musl-specific. The former is much broader in scope; the latter is > probably more intensive in the few areas it tests. > i know but i'm not content with either of those imho there should be one libctest repo which is a bit more organized than libc-testsuit and contains the cluts tests as well > > ok so using compound literal > > i was thinking about this > > something like this will work > > OK. > i saw that you removed the compound literal definition of NAN, INFINITY etc from math.h if we want to keep the headers c89 friendly then isnan, isinf,.. cannot be defined without function call maybe use static __isnanf,.. functions? (i committed a compound literal based implementatoin for now) > Yes, at least it would be a major undertaking to convert all the code > and ensure that no bugs are introduced. I think it's fine leaving it > how it is for now. I still want the fast isnan, etc. for applications > to use, though (and for use by other parts of libc like printf). > i agree > The semantics should only be changed if the goal is to consider > NAN/INF as "large" values too. Of course you also get abs() for free > using the representation and bitmask. Otherwise, for finite > comparisons comparing the representations and comparing the > floating-point values should have the same behavior. > hm but float compare will compile to different instruction so there is at least performance difference
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.