[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
