Date: Mon, 5 Mar 2012 09:04:59 -0500 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: libm On Mon, Mar 05, 2012 at 09:51:35AM +0100, Szabolcs Nagy wrote: > > > 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) Hm? If you need a macro to test whether an argument is an integer or floating point, try this: #define __IS_FP(x) !!((1?1:(x))/2) No assumptions at all. > even if we don't care about return types and int arguments > it seems tgmath is very ugly Yes, it is ugly. I don't think there's any way around the fact that tgmath.h is 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 I can do it, but might be another day or two. Feel free to keep fixing stuff up in the mean time if you have time. :) > > 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? The removal has nothing to do with c89; it's actually the fact that the compound literal definition was not a constant expression and the standard requires these macros to expand to constant expressions. As far as I know, gcc allows the compound literal even in old-standard modes, probably because it was a feature of "GNU C" long before C99 adopted it. In any case I see no good way to define them without compound literals except the function calls.. > > 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 Yes. In principle it would be faster to do everything as floating point so no store/load delays are needed. In relality I doubt it makes much of a difference. In almost all of these functions the actual computation time dominates. Rich
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.