Remove non-standard functions from OpenLibm #85
Conversation
I often build the code with -Wmissing-prototypes to ensure that we don't accidentically pollute the symbol namespace. If we want to provide a symbol such as isopenlibm(), make sure we also declare it in <openlibm_math.h>.
- Don't define llabs(). This breaks if llabs() is already a macro, which is allowed by the C standard/POSIX. llabs() was introduced in C99, so I think we can safely assume it is present on all interesting systems. - Cast the parameters to fabs() to the floating point type. Clang has introduced some interesting warnings that trigger if the arguments to fabs*() are not the right type.
Remove non-standard functions from OpenLibm
|
Thank you! |
|
Apparently julia still calls It would be fairly easy to implement these in Julia. |
|
I hadn't checked which of these we were using, but the 0.4.1 release of openlibm that we use for now still has these, so julia is safe. For the 0.5 release of openlibm, we will have to update julia too. |
|
We're also going to have to bump the SOVERSION major number if we remove functions from the ABI. Better do it in this PR before we forget. |
|
Already done in 763da44 |
|
We should put the single precision bessel functions back. Julia is using them and it doesn't hurt anything to have them in the library. The fact that a standard doesn't mention them is an omission in the standard. JuliaLang/julia#13868 |
|
I have been putting such things in openspecfun. I guess we could perhaps have a flag in openlibm that allows extra stuff too. However, seems like @yuyichao has a pure julia solution, which is perhaps even better. |
|
The pure julia implementation is pretty close in performance but is statistically significantly slower than the openlibm or libm implementation (which are the same one AFAICT....) by ~30%. Using I think this is a pretty fun exercise and probably also a useful benchmark to have but I also agree with Tony that there's little point of writing this in julia if the C version is already working and widely tested. It might make sense to ship a julia version if it can beat the C performance or if it provides other benefit. |
|
Agree. Just need a little bit more engg on the openlibm side for this. If we have an extensions flag in openlibm, we can even move rem_pio2 back from openspecfun back here. |
|
Hasn't |
|
I believe they are not part of the (C?) spec, but perhaps commonly implemented? The flag should just be a couple of lines in Makefile. So, if we reinstate these, it should be straightforward to have a flag. |
|
The http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/math.h.html |
Which is not a very convincing reason for not implementing them or even removing them from an existing library. |
|
@ViralBShah no tagging openlibm until single-precision bessel gets put back |
|
I guess all we need to do is revert 8c8693c |
|
And there have been upstream bugfixes in freebsd/freebsd-src@0563b7a and several other commits, but if those bugs aren't causing test failures in Julia then they aren't necessarily release blocking. |
|
4c8740a fixes this. I'd still like to bring in the EXTENSIONS build flag, but this should be good for now to tag. |
Hi Viral,
As mentioned in issue #79, I promised to send you a pull request to remove non-standard functions from OpenLibm, as they are only needed to keep existing implementations working. New implementations shouldn't offer them. This is how far I got.
Thanks,
Ed