fix fdlibm to use unions instead of unsafe pointer casts about julia HOT 25 CLOSED

You can give me some of your functions if you want; I'm done with mine (I have no life outside julia).

from julia.

OK, good, I can reproduce this on a 32-bit csail machine.

from julia.

Caused by building fdlibm with -O2 instead of -O1. It's officially time to fix the invalid pointer casts in fdlibm.
See fdlibm/math_private.h

from julia.

Or use crlibm.

from julia.

Yeah, maybe this is a good opportunity to try crlibm and/or the assembly language versions.

from julia.

Does anybody else use crlibm? Is it maintained?

from julia.

I have no idea if it's used, I'm afraid. I'm kind of shocked by the state of libm implementations in general — there just doesn't seem to be any single really good one. Although that pretty much reflects the general state of numerical computing as a whole, to be honest. We might need to pull together pieces of various implementations to stitch together something that's really as good as possible. Seems like a lot of annoying ancillary work.

from julia.

Would be a good advertisement for julia if everyone came to our website for openlibm. :-)

-viral

On Jun 15, 2011, at 10:46 AM, StefanKarpinski wrote:

I have no idea if it's used, I'm afraid. I'm kind of shocked by the state of libm implementations in general — there just doesn't seem to be any single really good one. Although that pretty much reflects the general state of numerical computing in general, to be honest. We might need to pull together pieces of various implementations to stitch together something that's really as good as possible. Seems like a lot of annoying ancillary work.

Reply to this email directly or view it on GitHub:
#46 (comment)

from julia.

Yeah, that's really not a bad idea, actually.

from julia.

Can we divvy up the files and fix this? There are 80 files to fix, about 26 each, and some of the files might not need changes, so it's not that bad.

from julia.

There are actually only 49 files that use the __LO and __HI macros. Here are the files, randomly divided into three groups, each assigned to one of us.

Jeff:

e_asin.c
e_cosh.c
e_hypot.c
e_pow.c
e_remainder.c
fdlibm.h
k_tan.c
s_atan.c
s_expm1.c
s_fabs.c
s_finite.c
s_frexp.c
s_logb.c
s_modf.c
s_nextafter.c
s_sin.c

Stefan:

e_acosh.c
e_atanh.c
e_fmod.c
e_j0.c
e_j1.c
e_jn.c
e_lgamma_r.c
e_log.c
e_log10.c
e_rem_pio2.c
k_cos.c
s_asinh.c
s_cbrt.c
s_floor.c
s_ilogb.c
s_isnan.c
s_tan.c

Viral:

e_acos.c
e_atan2.c
e_exp.c
e_log2.c
e_sinh.c
e_sqrt.c
k_sin.c
k_standard.c
s_ceil.c
s_copysign.c
s_cos.c
s_erf.c
s_log1p.c
s_rint.c
s_scalbn.c
s_tanh.c

Yes, I used Julia to do the dividing :-)

from julia.

Should we all send you patches so it goes in as a single commit?

from julia.

Can't the whole thing be done with sed or awk?

On 16-Jun-2011, at 3:44 AM, [email protected] wrote:

There are actually only 49 files that actually use the __LO and __HI macros. Here are the files, randomly divided into three groups, each assigned to one of us.

Jeff:

e_asin.c
e_cosh.c
e_hypot.c
e_pow.c
e_remainder.c
fdlibm.h
k_tan.c
s_atan.c
s_expm1.c
s_fabs.c
s_finite.c
s_frexp.c
s_logb.c
s_modf.c
s_nextafter.c
s_sin.c

Stefan:

e_acosh.c
e_atanh.c
e_fmod.c
e_j0.c
e_j1.c
e_jn.c
e_lgamma_r.c
e_log.c
e_log10.c
e_rem_pio2.c
k_cos.c
s_asinh.c
s_cbrt.c
s_floor.c
s_ilogb.c
s_isnan.c
s_tan.c

Viral:

e_acos.c
e_atan2.c
e_exp.c
e_log2.c
e_sinh.c
e_sqrt.c
k_sin.c
k_standard.c
s_ceil.c
s_copysign.c
s_cos.c
s_erf.c
s_log1p.c
s_rint.c
s_scalbn.c
s_tanh.c

Yes, I used Julia to do the dividing :-)

Reply to this email directly or view it on GitHub:
#46 (comment)

from julia.

Not in cases like if (__LO(x)...) where you need to introduce a temporary variable.

from julia.

I won't be able to touch code for the next 2-3 days - unfortunately. So, feel free to go down my list. Also, when I have time, I would like to focus on parallel HPL. Sorry about this one.

-viral

On Jun 16, 2011, at 7:35 AM, JeffBezanson wrote:

You can give me some of your functions if you want; I'm done with mine (I have no life outside julia).

Reply to this email directly or view it on GitHub:
#46 (comment)

from julia.

Re single vs. multiple patches. I don't think it matters. You can send me patches using gist. On the other hand, these can be fixed incrementally, so there's no real harm in multiple commits. I wouldn't mind seeing how you did yours as a guide for cases I may not be able to figure out. I haven't gotten a chance to tackle yet...

from julia.

OK, pushed (commit b248040). I will take Viral's functions.

from julia.

Sorry I didn't get a chance to do my functions before you did them. Thanks, Jeff.

from julia.

Oh, I thought you did them all — now I see that you just did more and that there are many usages of __LO and __HI still left.

from julia.

fixed the rest in commit 414ac2f

from julia.

Hmm, maybe native is a new gcc switch? Also, the trouble with native tuning is that you have to have a way to compile in code for all families for distribution. Cloud seems to get even more appealing for these kinds of reasons.

gcc -D_IEEE_LIBM -Dx86 -fPIC -O2 -march=native -c -o k_cos.o k_cos.c
k_cos.c:1: error: bad value (native) for -march= switch
k_cos.c:1: error: bad value (native) for -mtune= switch
make[2]: *** [k_cos.o] Error 1
make[1]: *** [fdlibm/libfdm.dylib] Error 2
make: *** [julia-release] Error 2

-viral

On Jun 17, 2011, at 1:43 AM, JeffBezanson wrote:

fixed the rest in commit 414ac2f

Reply to this email directly or view it on GitHub:
#46 (comment)

from julia.

Its odd I get that error, even when native is discussed in my gcc manpage.

-viral

On Jun 17, 2011, at 1:45 AM, Viral Shah wrote:

Hmm, maybe native is a new gcc switch? Also, the trouble with native tuning is that you have to have a way to compile in code for all families for distribution. Cloud seems to get even more appealing for these kinds of reasons.

gcc -D_IEEE_LIBM -Dx86 -fPIC -O2 -march=native -c -o k_cos.o k_cos.c
k_cos.c:1: error: bad value (native) for -march= switch
k_cos.c:1: error: bad value (native) for -mtune= switch
make[2]: *** [k_cos.o] Error 1
make[1]: *** [fdlibm/libfdm.dylib] Error 2
make: *** [julia-release] Error 2

-viral

On Jun 17, 2011, at 1:43 AM, JeffBezanson wrote:

fixed the rest in commit 414ac2f

Reply to this email directly or view it on GitHub:
#46 (comment)

from julia.

sqrt() seems to run about 20-30% faster than before, if memory serves correctly.

-viral

On Jun 17, 2011, at 1:45 AM, Viral Shah wrote:

Hmm, maybe native is a new gcc switch? Also, the trouble with native tuning is that you have to have a way to compile in code for all families for distribution. Cloud seems to get even more appealing for these kinds of reasons.

gcc -D_IEEE_LIBM -Dx86 -fPIC -O2 -march=native -c -o k_cos.o k_cos.c
k_cos.c:1: error: bad value (native) for -march= switch
k_cos.c:1: error: bad value (native) for -mtune= switch
make[2]: *** [k_cos.o] Error 1
make[1]: *** [fdlibm/libfdm.dylib] Error 2
make: *** [julia-release] Error 2

-viral

On Jun 17, 2011, at 1:43 AM, JeffBezanson wrote:

fixed the rest in commit 414ac2f

Reply to this email directly or view it on GitHub:
#46 (comment)

from julia.

We still need to see if the assembly language sqrt is accurate enough. The
Intel manual doesn't say anything about it.

On Thu, Jun 16, 2011 at 4:24 PM, ViralBShah <
[email protected]>wrote:

sqrt() seems to run about 20-30% faster than before, if memory serves
correctly.

-viral

On Jun 17, 2011, at 1:45 AM, Viral Shah wrote:

Hmm, maybe native is a new gcc switch? Also, the trouble with native
tuning is that you have to have a way to compile in code for all families
for distribution. Cloud seems to get even more appealing for these kinds of
reasons.

gcc -D_IEEE_LIBM -Dx86 -fPIC -O2 -march=native -c -o k_cos.o k_cos.c
k_cos.c:1: error: bad value (native) for -march= switch
k_cos.c:1: error: bad value (native) for -mtune= switch
make[2]: *** [k_cos.o] Error 1
make[1]: *** [fdlibm/libfdm.dylib] Error 2
make: *** [julia-release] Error 2

-viral

On Jun 17, 2011, at 1:43 AM, JeffBezanson wrote:

fixed the rest in commit 414ac2f

Reply to this email directly or view it on GitHub:
#46 (comment)

Reply to this email directly or view it on GitHub:
#46 (comment)

from julia.

Ok. I meant the fdlibm sqrt with -O2 is faster than before.

-viral

On Jun 17, 2011, at 1:56 AM, JeffBezanson wrote:

We still need to see if the assembly language sqrt is accurate enough. The
Intel manual doesn't say anything about it.

On Thu, Jun 16, 2011 at 4:24 PM, ViralBShah <
[email protected]>wrote:

sqrt() seems to run about 20-30% faster than before, if memory serves
correctly.

-viral

On Jun 17, 2011, at 1:45 AM, Viral Shah wrote:

Hmm, maybe native is a new gcc switch? Also, the trouble with native
tuning is that you have to have a way to compile in code for all families
for distribution. Cloud seems to get even more appealing for these kinds of
reasons.

gcc -D_IEEE_LIBM -Dx86 -fPIC -O2 -march=native -c -o k_cos.o k_cos.c
k_cos.c:1: error: bad value (native) for -march= switch
k_cos.c:1: error: bad value (native) for -mtune= switch
make[2]: *** [k_cos.o] Error 1
make[1]: *** [fdlibm/libfdm.dylib] Error 2
make: *** [julia-release] Error 2

-viral

On Jun 17, 2011, at 1:43 AM, JeffBezanson wrote:

fixed the rest in commit 414ac2f

Reply to this email directly or view it on GitHub:
#46 (comment)

Reply to this email directly or view it on GitHub:
#46 (comment)

Reply to this email directly or view it on GitHub:
#46 (comment)

from julia.