juliamath / openlibm Goto Github PK

View Code? Open in Web Editor NEW

491.0 40.0 133.0 4.18 MB

High quality system independent, portable, open source libm implementation

Home Page: https://openlibm.org

License: Other

C 93.76% Assembly 4.15% C++ 0.17% Makefile 0.35% CMake 1.28% BitBake 0.28%

openlibm math-library c cross-platform

openlibm's Introduction

OpenLibm

OpenLibm is an effort to have a high quality, portable, standalone C mathematical library (libm). It can be used standalone in applications and programming language implementations.

The project was born out of a need to have a good libm for the Julia programming language that worked consistently across compilers and operating systems, and in 32-bit and 64-bit environments.

Platform support

OpenLibm builds on Linux, macOS, Windows, FreeBSD, OpenBSD, NetBSD, and DragonFly BSD. It builds with both GCC and clang. Although largely tested and widely used on the x86 and x86-64 architectures, OpenLibm also supports arm, aarch64, ppc64le, mips, wasm32, riscv, s390(x) and loongarch64.

Build instructions

GNU Make

Use GNU Make to build OpenLibm. This is make on most systems, but gmake on BSDs.
Use make USEGCC=1 to build with GCC. This is the default on Linux and Windows.
Use make USECLANG=1 to build with clang. This is the default on OS X, FreeBSD, and OpenBSD.
Use make ARCH=wasm32 to build the wasm32 library with clang.
Architectures are auto-detected. Use make ARCH=i386 to force a build for i386. Other supported architectures are i486, i586, and i686. GCC 4.8 is the minimum requirement for correct codegen on older 32-bit architectures.

Cross Build Take riscv64 as example:

install qemu-riscv64-static, gcc-riscv64-linux-gnu
Cross build:

ARCH=riscv64
TRIPLE=$ARCH-linux-gnu
make ARCH=$ARCH TOOLPREFIX=$TRIPLE-  -j
make -C test ARCH=$ARCH TOOLPREFIX=$TRIPLE-  -j

Run test with qemu:

qemu-$ARCH-static -L . -L /usr/$TRIPLE/  test/test-float
qemu-$ARCH-static -L . -L /usr/$TRIPLE/  test/test-double

CMake

Create build directory with mkdir build and navigate into it with cd build.
Run CMake to configure project and generate native build system with cmake /path/to/openlibm/ or generate project with build system of choice e.g. cmake /path/to/openlib/ -G "MinGW Makefiles".
Build with the build system with cmake --build ..

Default CMake configuration builds a shared library, this can easily be changed by replacing the keyword in the add_library() command in the CMakeLists.txt.

Acknowledgements

PowerPC support for openlibm was graciously sponsored by IBM.

openlibm's People

Contributors

Stargazers

Watchers

Forkers

vtjnash nahratzah ihnorton nalimilan zbrdge tkelman talex5 eschnett neuroradiology acw jfla scialex wyvern92 reap720801 douglas-larocca zhmz90 djwillia nosuchprocess iblislin wdv4758h xianyi antonblanchard sarikayamehmet 447327642 kleopatra999 edschouten himanshugoel2797 hannesm arjenroodselaar twadleigh sharkcz rbirdic yws mato miguelraz axfab certik szaydel pkofod emsr takuyanakaoka meulengracht haoj-huang redox-os nopsys goodwenxi kalamatee ararslan shingtaklam1324 sjc cmhc tlming16 mingwangzhong chenishi mcmocoder klaven slunski malofficial minad srkos-htec xclshwd jkliang9714 penguindoom sitedata jaredwright llucinat nickwanninger thepigrepper zuoq3 bolterr cndesantana alphadelta14 forksnd httese embeddedartistry edwin-xu huaqli seiko2plus tonyhuang1976 jcestibariz maleadt genisysram petteriaimonen standardgalactic fp4code lephe 1610488836zq n5n3 sgstreet t-bltg xctan mr1name pheihuihui xilongpei frostyfeng munemasa luiskoo juztamau5 skiars ajunlonglive

openlibm's Issues

Complete loss of precision for trig reduction in non-default rounding modes

The trig-reduction implementations assume that the rounding mode is round-to-nearest, and do not function correctly if it isn't. Example: sinf(-0x1.4665d2p+27). The mathematically precise result is approximately -0x1.927bcc77af475p-25, but in round-toward-zero or round-down, openlibm computes a result of -0x1.a2c7eep-17.

This behavior is especially bad for the "medium argument" path in rem_pio2f. When the argument is so large that you punt to rem_pio2, double-precision has enough extra bits to still deliver relatively good results.

SONAME handling

(this is similar to JuliaMath/openspecfun#19)

The SONAME of openlibm is currently libopenlibm0.3.0. In other words, it contains the version number.

This is not good practice. The SONAME should not follow the same sequence as version numbers. The SONAME should only change when the ABI changes in a backward-incompatible way.

The practical consequence of having the SONAME equal to the version number is that all binaries linked against openlibm will have to be recompiled everytime there is a new openlibm version. In other words, it is almost as if openlibn was only available as a static library. This is particularly painful for Linux distributions.

Would it be possible to move to a more standard SONAME handling? Of course, this implies that you must track ABI changes and increment the SONAME if there is a backward incompatible ABI change. For a library with a stable ABI like a libm implementation, the SONAME should very rarely (if ever) change.

Version number/Release

I'm going to package this in the julia-deps PPA; does openlibm have a version number I can publish?

rem_pio2 computed incorrectly on i486

Originally reported at JuliaLang/julia#4850

sin() appears to be returning the wrong value:

make test-math
    JULIA test/math
     * math
exception on 1: ERROR: assertion failed: |:(sinpi(x)) - :(sin(*(pi,x)))| <= 1.7763568394002505e-15
  :(sinpi(x)) = -0.8090169943749471
  :(sin(*(pi,x))) = -0.9999999882345147
  difference = 0.19098299385956763 > 1.7763568394002505e-15
(...)

However, if I use the system libm, the tests pass:

make test-math USE_SYSTEM_LIBM=1
    JULIA test/math
     * math
    SUCCESS

Test failures on ARM

Running test/test-double gives lots of test failures on ARM. In many cases, the invalid operation exception is set, when it should not be and other cases, divide by zero is not set when it should be.

The tests don't run to completion and hang currently.

If I build test-double-system that uses the system libm, there are only 2 minor errors.

Test failures when using clang

A number of tests are off by 1 ulp with clang. This could be because the tests are wrong, or clang is doing something wrong, or because openlibm is doing something wrong.

$ ./test-double
testing double (without inline functions)
Failure: Test: sinh (0.7) == 0.75858370183953350346
Result:
 is:          7.58583701839533386391e-01   0x1.8465153d5bdbc0000000p-1
 should be:   7.58583701839533497413e-01   0x1.8465153d5bdbd0000000p-1
 difference:  1.11022302462515654042e-16   0x1.00000000000000000000p-53
 ulp       :  1.0000
 max.ulp   :  0.0000
Maximal error of `sinh'
 is      :  1.0000 ulp
 accepted:  0.0000 ulp
Failure: Test: tanh (0.7) == 0.60436777711716349631
Result:
 is:          6.04367777117163607059e-01   0x1.356fb17af2e920000000p-1
 should be:   6.04367777117163496037e-01   0x1.356fb17af2e910000000p-1
 difference:  1.11022302462515654042e-16   0x1.00000000000000000000p-53
 ulp       :  1.0000
 max.ulp   :  0.0000
Failure: Test: tanh (-0.7) == -0.60436777711716349631
Result:
 is:         -6.04367777117163607059e-01  -0x1.356fb17af2e920000000p-1
 should be:  -6.04367777117163496037e-01  -0x1.356fb17af2e910000000p-1
 difference:  1.11022302462515654042e-16   0x1.00000000000000000000p-53
 ulp       :  1.0000
 max.ulp   :  0.0000
Maximal error of `tanh'
 is      :  1.0000 ulp
 accepted:  0.0000 ulp
Failure: Test: exp (1) == e
Result:
 is:          2.71828182845904553488e+00   0x1.5bf0a8b14576a0000000p+1
 should be:   2.71828182845904509080e+00   0x1.5bf0a8b1457690000000p+1
 difference:  4.44089209850062616169e-16   0x1.00000000000000000000p-51
 ulp       :  1.0000
 max.ulp   :  0.0000
Maximal error of `exp'
 is      :  1.0000 ulp
 accepted:  0.0000 ulp
Failure: Test: expm1 (1) == M_El - 1.0
Result:
 is:          1.71828182845904509080e+00   0x1.b7e151628aed20000000p+0
 should be:   1.71828182845904531284e+00   0x1.b7e151628aed30000000p+0
 difference:  2.22044604925031308085e-16   0x1.00000000000000000000p-52
 ulp       :  1.0000
 max.ulp   :  0.0000
Maximal error of `expm1'
 is      :  1.0000 ulp
 accepted:  0.0000 ulp
Failure: log (0) == -inf plus division by zero exception: Exception "Divide by zero" not set
Failure: log (-0) == -inf plus division by zero exception: Exception "Divide by zero" not set
Failure: log10 (0) == -inf plus division by zero exception: Exception "Divide by zero" not set
Failure: log10 (-0) == -inf plus division by zero exception: Exception "Divide by zero" not set
Failure: log1p (-1) == -inf plus division by zero exception: Exception "Divide by zero" not set
Failure: log2 (0) == -inf plus division by zero exception: Exception "Divide by zero" not set
Failure: log2 (-0) == -inf plus division by zero exception: Exception "Divide by zero" not set
Failure: gamma (0) == inf plus division by zero exception: Exception "Divide by zero" not set
Failure: gamma (-3) == inf plus division by zero exception: Exception "Divide by zero" not set
Failure: lgamma (0) == inf plus division by zero exception: Exception "Divide by zero" not set
Failure: lgamma (-3) == inf plus division by zero exception: Exception "Divide by zero" not set
Failure: tgamma (0) == NaN plus invalid exception: Exception "Divide by zero" set
Failure: tgamma (0) == NaN plus invalid exception: Exception "Invalid operation" not set
Failure: Test: tgamma (0) == NaN plus invalid exception
Result:
 is:          inf   inf
 should be:  nan  nan
Failure: tgamma (-0) == NaN plus invalid exception: Exception "Divide by zero" set
Failure: tgamma (-0) == NaN plus invalid exception: Exception "Invalid operation" not set
Failure: Test: tgamma (-0) == NaN plus invalid exception
Result:
 is:         -inf  -inf
 should be:  nan  nan
Failure: Test: j1 (8.0) == 0.23463634685391462438
Result:
 is:          2.34636346853914601329e-01   0x1.e0890561861820000000p-3
 should be:   2.34636346853914629085e-01   0x1.e0890561861830000000p-3
 difference:  2.77555756156289135106e-17   0x1.00000000000000000000p-55
 ulp       :  1.0000
 max.ulp   :  0.0000
Failure: Test: jn (1, 8.0) == 0.23463634685391462438
Result:
 is:          2.34636346853914601329e-01   0x1.e0890561861820000000p-3
 should be:   2.34636346853914629085e-01   0x1.e0890561861830000000p-3
 difference:  2.77555756156289135106e-17   0x1.00000000000000000000p-55
 ulp       :  1.0000
 max.ulp   :  0.0000
Failure: Test: jn (10, 0.1) == 0.26905328954342155795e-19
Result:
 is:          2.69053289543421753151e-20   0x1.fc3a2ffb93d410000000p-66
 should be:   2.69053289543421572595e-20   0x1.fc3a2ffb93d3b0000000p-66
 difference:  1.80555932286303361224e-35   0x1.80000000000000000000p-116
 ulp       :  6.0000
 max.ulp   :  5.0000
Maximal error of `jn'
 is      :  6.0000 ulp
 accepted:  5.0000 ulp
Failure: Test: y0 (-1.0) == -inf
Result:
 is:         nan  nan
 should be:  -inf  -inf
Failure: Test: y1 (-1.0) == -inf
Result:
 is:         nan  nan
 should be:  -inf  -inf
Failure: Test: y1 (8.0) == -0.15806046173124749426
Result:
 is:         -1.58060461731247520190e-01  -0x1.43b5340f693370000000p-3
 should be:  -1.58060461731247492434e-01  -0x1.43b5340f693360000000p-3
 difference:  2.77555756156289135106e-17   0x1.00000000000000000000p-55
 ulp       :  1.0000
 max.ulp   :  0.0000
Failure: Test: yn (0, -1.0) == -inf
Result:
 is:         nan  nan
 should be:  -inf  -inf
Failure: Test: yn (1, -1.0) == -inf
Result:
 is:         nan  nan
 should be:  -inf  -inf
Failure: Test: yn (1, 8.0) == -0.15806046173124749426
Result:
 is:         -1.58060461731247520190e-01  -0x1.43b5340f693370000000p-3
 should be:  -1.58060461731247492434e-01  -0x1.43b5340f693360000000p-3
 difference:  2.77555756156289135106e-17   0x1.00000000000000000000p-55
 ulp       :  1.0000
 max.ulp   :  0.0000

Test suite completed:
  1129 test cases plus 944 tests for exception flags executed.
  36 errors occurred.

Definition of isinf

This issue captures issues related to building openlibm due to isinf. Essentially, I am using __isinf, which is dangerous, and things fail to build because isinf may not be available.

After searching wikipedia more, I determined the last definition is only correct for programs compiled with gcc on x86 (and gcc-clang apparently on x86) and that it may be fragile for GCC > 4.3. There really doesn't seem to me to be a portable way of determining infinity for anything larger than float and double without including math.h.
-Jameson

On Thu, Jan 5, 2012 at 10:27 AM, Viral Shah [email protected] wrote:
Ah - I just saw the bug report. Will try to get it to build on linux next.

-viral

On Jan 5, 2012, at 8:54 PM, Jameson Nash wrote:

Actually, I think a better definition would be:

define __isinff(x) (x & ~(1<<31)) == 0x7f800000

define __isinfd(x) (x & ~(1<<63)) == 0x7ff0000000000000

define __isinfl(x) (x & ~(1<<79)) == 0x7fff8000000000000000

Although that last one is not exactly correct and I'm not sure what happens with bit manipulations of floating point numbers. It may be necessary to cast them to a sufficiently large uint first.

I don't consider inf_torture.c as much of a math test as I do of a way to break your compiler. Providing things like assert(isinf((double)1./0)) and assert(!isnan((double)1./0)) would make a better test suite.

Openlibm currently doesn't build on linux (see Jeff's bug report) since it doesn't have the necessary BSD headers.

-jameson

On Thu, Jan 5, 2012 at 1:55 AM, Viral Shah [email protected] wrote:
We can get the inlining working later - seems unnecessary right now.

Do you feel comfortable enough to make those the definitions for isinf* in openlibm for now? If so, can you create a merge request, or commit directly to the openlibm repo? You should be able to commit to it.

Need to try openlibm on linux, which I haven't even tried.

Would be nice to add the torture test to the repo as well. I am hoping that over time, we have a high quality test-suite in openlibm.

-viral

On Jan 5, 2012, at 11:51 AM, Jameson Nash wrote:
I think they inlined to get those last few extra percentage points of speed by eliminating the function call, which could presumably matter when putting this into some heavily optimized graphics loop.

Replacing isinf with __isinf works fine on Apple, which is probably already using a derivative of FDLIBM underneath and happens to have the correct definitions in this case (it is a BSD port after all). Otherwise, this is a really bad idea since it disables all type-checking in potentially stack destroying ways (or subtle bug inducing ways) if the definitions used by the compiler are different. Remember the bug I tracked down with the 8 bit boxing of Julia types? It would be like that. I've attached some c code I wrote to delve into this on 64-bit Apple. Results on other compilers / computer not strictly guaranteed, although I've shown it to work on 32-bit Ubuntu also. See some of the different results you can get with gcc vs clang, with and without compiler optimizations (-ffast-math and -O3 for starters).

It does however suggest a portable definition for isinf that seems sort-of likely to work of:

define isinff(x) x == x && x > 0xff800000

define isinfd(x) x == x && x > 0x7ff0000000000000

define isinfl(x) x == x && x > 0x7fff8000000000000000

5. NOTES ON PORTING FDLIBM
  Care must be taken when installing FDLIBM over existing
  libm.a.
  All co-existing function prototypes must agree, otherwise
  users will encounter mysterious failures.

  So far, the only known likely conflict is the declaration
  of the IEEE recommended function scalb:

          double scalb(double,double)     (1)     SVID3 defined
          double scalb(double,int)        (2)     IBM,DEC,...

  FDLIBM follows Sun definition and use (1) as default.
  If one's existing libm.a uses (2), then one may raise
  the flags _SCALB_INT during the compilation of FDLIBM
  to get the correct function prototype.
  (E.g., make "CFLAGS = -D_IEEE_LIBM -D_SCALB_INT".)
  NOTE that if -D_SCALB_INT is raised, it won't be SVID3
  conformant.
-Jameson
<inf_torture.c>

On Jan 1, 2012, at 10:40 PM, Viral Shah wrote:
Yes, the whole inline thing is really confusing. I have got the whole thing building, and even loading in julia. See math_openlibm.j in examples.

I will try out your inline branch. I don't want to include the system math.h, because that is exactly what I want to avoid with openlibm. I replaced isinf with __isinf and it worked.

-viral

On Jan 2, 2012, at 7:29 AM, Jameson Nash wrote:
That's odd, since on my Apple it worked.

Anyways, I've forked your repo and created two branches. The first "inline" is simply getting it to build with inline support. The second "system_math_h_plus" is a (possibly foolish) attempt to include the system math.h header to pull in the proper compiler built in functions, macros, and constants (mostly for isinf and the sizes of a few other things). Both compile for me.

To get it to work on linux (Ubuntu) for Jeff, I think you'll need to pull in the sys/cdefs.h file from the original BSD system to get the definitions of things like __pure2.

More information on inline from the Apple man page for gcc (I just find all of it very confusing):
-fgnu89-inline
The option -fgnu89-inline tells GCC to use the traditional GNU
semantics for "inline" functions when in C99 mode.
Using this option is roughly equivalent to adding the
"gnu_inline" function attribute to all inline functions.
     This option is accepted by GCC versions 4.1.3 and up.  In GCC
     versions /* APPLE LOCAL extern inline */ prior to 4.3 (4.2 for
     Apple's gcc), C99 inline semantics are not supported, and thus this
     option is effectively assumed to be present regardless of whether
     or not it is specified; the only effect of specifying it explicitly
     is to disable warnings about using inline functions in C99 mode.
     Likewise, the option -fno-gnu89-inline is not supported in versions
     of /* APPLE LOCAL extern inline */ GCC before 4.3 (4.2 for Apple's
     gcc).  It is supported only in C99 or gnu99 mode, not in C89 or
     gnu89 mode.

     The preprocesor macros "__GNUC_GNU_INLINE__" and
     "__GNUC_STDC_INLINE__" may be used to check which semantics are in
     effect for "inline" functions.
On Dec 31, 2011, at 11:08 PM, Viral Shah wrote:

I guess Apple's shipped gcc does not fully support this inline stuff?

http://gcc.gnu.org/gcc-4.2/c99status.html

-viral

On Jan 1, 2012, at 1:47 AM, Jameson Nash wrote:

Here's an interesting resource on inline functions. http://www.greenend.org.uk/rjk/2003/03/inline.html It takes a bit of work to understand, but can help clear up the issue. In summary, it needs to be compiled with CFLAGS += -std=c99 (and revert your recent changes to the makefile and c files)
-Jameson

On Dec 31, 2011, at 3:12 PM, Viral Shah wrote:

I got it to that stage too. Perhaps we can just try to build without the "long double" versions.

-viral

On Jan 1, 2012, at 1:04 AM, Jameson Nash wrote:

I can get it to compile with a few fixes, however, I don't have a real definition for __isinfl (on Mac OS Lion / llvm-gcc), which is preventing linking.
-Jameson

On Dec 31, 2011, at 9:21 AM, Viral Shah wrote:

I have separated out the libm implementation from FreeBSD and am trying to build it standalone. I have it almost there, except a couple of long double things not building, and a couple of link time errors.

https://github.com/JuliaLang/openlibm

I have marked every change with VBS, where I had to make some small tweaks to get things to compile.

I want to have all the libm functions then be prefixed with olm_ so that the library can be dropped in anywhere, and one can be absolutely sure of which functions are getting called etc. Next, I will plug it into julia, and it gives us many more complex functions. I then plan to start slowly writing tests for every function along the lines of Alan's numerical wiki, clean the style etc.

Would be nice if anyone who is interested can take a look at my edits, and help get it going.

-viral

Useless arithmetic in k_cos.c?

I must be missing something, but I can't figure out why we have this arithmetic in k_cos.c:

w  = one-hz;
return w + (((one-w)-hz) + (z*r-x*y));

It seems to me that since w = one-hz, we can get rid of that first term in the parentheses. Removing that term doesn't affect the testsuite at all, so I'm wondering if I'm missing some kind of "signed zero" special case or something.

use __builtin_complex in gcc 4.7+ for cpack, and CMPLX macro in C11

In math_private.h, you have a function called cpack to construct complex numbers. This was standardized in C11 as the CMPLX macro, and is supported natively in gcc 4.7+ by a builtin called __builtin_complex ... it would be good to use these if they are available.

e.g. do:

#ifdef CMPLX /* C11 macro is available */
#  define cpack(x,y) CMPLX(x,y)
#elif (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 7)) && !defined(__INTEL_COMPILER)
#  define cpack(x,y) __builtin_complex((double) (x), (double) (y))
#else
static __inline double complex cpack(double x, double y) { .... }
#endif

Note that I would recommend checking !defined(INTEL_COMPILER) to be safe: icc lies and claims to be gcc (it defines _GNUC), but does not in general support all gcc features. I haven't heard anything about whether icc will support __builtin_complex.

IEEE 754 compatiblity

Does this library conform to IEEE 754, insofar as the instructions it uses do? If so, could this be noted (prominently) in the readme?

test-float failure

test-float fails on Fedora 20 both 32 and 64 bits, and thus probably elsewhere (same output of both archs). Though the difference isn't that big, it means I cannot run the automated tests when building package. test-double passes.

+ ./test-float
testing float (without inline functions)
Failure: Test: erfc (1.2) == 0.089686021770364619762
Result:
 is:          8.96860063076019287109e-02   0x1.6f5a9800000000000000p-4
 should be:   8.96860212087631225586e-02   0x1.6f5a9c00000000000000p-4
 difference:  1.49011611938476562500e-08   0x1.00000000000000000000p-26
 ulp       :  2.0000
 max.ulp   :  1.0000
Failure: Test: yn (3, 0.7) == -15.819479052819633505
Result:
 is:         -1.58194799423217773438e+01  -0x1.fa392e00000000000000p+3
 should be:  -1.58194789886474609375e+01  -0x1.fa392c00000000000000p+3
 difference:  9.53674316406250000000e-07   0x1.00000000000000000000p-20
 ulp       :  1.0000
 max.ulp   :  0.0000

Inclusion of arch specific files

@loladiro

Currently, the Makefile doesn't have a way to override the generic implementation with arch specific assembly implementation.

We could steal some Make infrastructure from FreeBSD as well:

http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/msun/Makefile?rev=1.98.2.4.2.1;content-type=text%2Fplain

Use of Fortran compiler to link libopenlibm.so?

On https://github.com/JuliaLang/openlibm/blob/master/Makefile#L29, a Fortran compiler is used to link the libopenlibm shared library. There is currently no Fortran in openlibm (guessing it was split out to openspecfun?). If it's expected that this will remain the case, can the C compiler be used for linking instead?

Build on Raspberry Pi 2 fails ( ARM )

Downloaded and tried to make the latest version of openlibm, as part of the install process for Julia, the build failed with the following error:

s_cargl.c:(.text+0x0): multiple definition of `carg'
src/s_carg.c.o:s_carg.c:(.text+0x0): first defined here
src/s_cpowl.c.o: In function `cpow':
s_cpowl.c:(.text+0x0): multiple definition of `cpow'
src/s_cpow.c.o:s_cpow.c:(.text+0x0): first defined here
src/s_cimagl.c.o: In function `cimag':
s_cimagl.c:(.text+0x0): multiple definition of `cimag'
src/s_cimag.c.o:s_cimag.c:(.text+0x0): first defined here
src/s_conjl.c.o: In function `conj':
s_conjl.c:(.text+0x0): multiple definition of `conj'
src/s_conj.c.o:s_conj.c:(.text+0x0): first defined here
src/s_creall.c.o: In function `creal':
s_creall.c:(.text+0x0): multiple definition of `creal'
src/s_creal.c.o:s_creal.c:(.text+0x0): first defined here
collect2: error: ld returned 1 exit status
Makefile:35: recipe for target 'libopenlibm.so' failed
make: *** [libopenlibm.so] Error 1

Should this library have been pulled in automatically as part of the Julia build process?
'make julia' failed with the following error:

 collect2: error: ld returned 1 exit status
Makefile:35: recipe for target 'libopenlibm.so' failed
make[2]: *** [libopenlibm.so] Error 1
Makefile:790: recipe for target 'openlibm/libopenlibm.so' failed
make[1]: *** [openlibm/libopenlibm.so] Error 2
Makefile:60: recipe for target 'julia-deps' failed
make: *** [julia-deps] Error 2

It was this error which lead me to try to install openlibm manually.

The operating system is Raspbian.

How can I help resolve this ?

cheers :)

don't use fsin and fcos on i387

erf optimizations

I don't know if this is of interest to openlibm, but recently I did some work in FFmpeg to get in an erf implementation (on broken libms as a fallback) that was fast (~1.5x GNU/openlibm) and reasonably accurate:
FFmpeg/FFmpeg@dd68cde.
Please note that FFmpeg can afford to be slightly more lax wrt accuracy, since it tends to weigh performance more heavily and also because it needs to work with all kinds of upstream libm's so it can't rely on "correctly rounded" functions. Nevertheless, as seen in the message, it is reasonably accurate, and in some cases is correctly rounded when GNU/openlibm are not.

In summary, if people here think this is promising, and that one can use this approach with some possible tweaks in case accuracy is of interest, I can work further on this and come up with something concrete.

Missing cpow()

I'm trying to compile our test/perf/micro set against openlibm, but we lack cpow(). I noticed that in test/libm-test.c the cpow() stuff is all #if 0'ed into oblivion; is this just because we don't need cpow() in Julia, or because of some deeper problem?

undefined references in linux build

I get the following output building with make on linux x86_64:

    LINK libopenlibm.a
    LINK libopenlibm.so
make -C test
make[1]: Entering directory `/home/jeff/src/julia2/openlibm/test'
Makefile:19: warning: overriding recipe for target `clean'
../Make.inc:27: warning: ignoring old recipe for target `clean'
gcc -g test-double.c -D__BSD_VISIBLE -I ../include -I../src ../libopenlibm.a -o test-double
In file included from test-double.c:34:0:
libm-test.c:227:6: warning: conflicting types for built-in function ‘sincos’ [enabled by default]
/tmp/ccWlbniv.o: In function `init_max_error':
/home/jeff/src/julia2/openlibm/test/libm-test.c:239: undefined reference to `feclearexcept'
/tmp/ccWlbniv.o: In function `test_single_exception':
/home/jeff/src/julia2/openlibm/test/libm-test.c:434: undefined reference to `fetestexcept'
/home/jeff/src/julia2/openlibm/test/libm-test.c:449: undefined reference to `fetestexcept'
/tmp/ccWlbniv.o: In function `test_exceptions':
/home/jeff/src/julia2/openlibm/test/libm-test.c:488: undefined reference to `feclearexcept'
/tmp/ccWlbniv.o: In function `gamma_test':
/home/jeff/src/julia2/openlibm/test/libm-test.c:2787: undefined reference to `feclearexcept'
/tmp/ccWlbniv.o: In function `lgamma_test':
/home/jeff/src/julia2/openlibm/test/libm-test.c:3080: undefined reference to `feclearexcept'
/tmp/ccWlbniv.o: In function `tgamma_test':
/home/jeff/src/julia2/openlibm/test/libm-test.c:4125: undefined reference to `feclearexcept'
/tmp/ccWlbniv.o: In function `initialize':
/home/jeff/src/julia2/openlibm/test/libm-test.c:4338: undefined reference to `feclearexcept'
../libopenlibm.a(s_fma.c.o): In function `fma':
s_fma.c:(.text+0x383): undefined reference to `feraiseexcept'
s_fma.c:(.text+0x541): undefined reference to `feraiseexcept'
../libopenlibm.a(s_nearbyint.c.o): In function `nearbyint':
s_nearbyint.c:(.text+0xf): undefined reference to `fegetenv'
../libopenlibm.a(s_nearbyint.c.o): In function `nearbyintf':
s_nearbyint.c:(.text+0x3f): undefined reference to `fegetenv'
../libopenlibm.a(s_nearbyint.c.o): In function `nearbyintl':
s_nearbyint.c:(.text+0x6a): undefined reference to `fegetenv'
collect2: error: ld returned 1 exit status
make[1]: *** [test-double] Error 1
make[1]: Leaving directory `/home/jeff/src/julia2/openlibm/test'
make: *** [all] Error 2

test-double failure on i686

We're seeing this failure when running test-double on a 32-bit Fedora VM. This test passes on 64-bit.

./test-double
testing double (without inline functions)
FP-Stack wrong after test exp (-0) == 1 (2, should be 0)
Test suite completed:
  1148 test cases plus 962 tests for exception flags executed.
  1 errors occurred.

Performance Benchmark

I am not sure whether there has already been some way to keep track of the performance in this library.

Recently, I wrote a simple program for comparing the performance of openlibm functions and those in Mac OS X's built in libm.

Here are the results I obtained on my macbook pro:

             builtin libm       openlibm
  pow     :  231.7306 MPS    263.3389 MPS
  hypot   :  315.7839 MPS     95.3319 MPS
  exp     :  194.7099 MPS    181.3417 MPS
  log     :  196.3819 MPS    292.3016 MPS
  log10   :  194.7113 MPS    271.7385 MPS
  sin     :  267.9796 MPS    252.3046 MPS
  cos     :  292.1543 MPS    234.5709 MPS
  tan     :  247.9816 MPS    271.1547 MPS
  asin    :  193.5040 MPS    206.4639 MPS
  acos    :  195.3668 MPS    234.2596 MPS
  atan    :  152.3752 MPS    220.0147 MPS
  atan2   :  167.9623 MPS    183.5705 MPS

Here, MPS means millions (call) per second.

Generally, openlibm performs quite well. However, there are several important functions where openlibm still falls behind, which include hypot, exp, sin, and cos. Particularly, hypot is over 3x slower (less than 100 MPS is overly too slow for such a simple function).

openlibm.h #includes "cdefs-compat.h"

Currently a program including openlibm.h (as openspecfun does) fails to build because openlibm.h contains:

#include "cdefs-compat.h"
#include "types-compat.h"

and these files are not installed.

Should the files under include/ go to $prefix/include/openlibm/?

Build Errors from math.h -> openlibm.h in src/s_cpow.c

I was getting build failures on a CentOS 5 system with gcc44 and gfortran44. @nolta mentioned that it might be due to the math.h includes mentioned in this commit message.

And indeed, when I changed math.h -> openlibm.h in in src/s_cpow.c, src/s_cpowf.c, and src/s_cpowl.c then the build succeeded.

fmod for 64bit is slow

The fmod function on x86_64 is pretty slow (e.g. roughly 5x slower than remainder, or fmod in the os x libm). From what I understand of the Makefile, it is using the src/e_fmod.c, which is implemented in software. The other remainder functions (remainder, remquo) use the assembly implementations in amd64 (which use x87 instructions).

I should mention that this isn't a problem for Julia at the moment, as we access fmod through the LLVM intrinsic, which in turn calls the system libm. But if this were to change, we would see a significant performance hit.

olm_ prefixes for openlibm functions

@vtjnash, @loladiro, Do you think we should have olm_ prefixes for openlibm functions, so that they don't clash with the system libm?

This could be done through a macro, which allows use of libm names, or with a prefix, depending on what the user wants.

compiler warnings

The compiler is producing a number of warnings that seem like possible mistakes in the code. @ViralBShah: any chance you can look through them?

Test suite

We need a comprehensive testsuite for openlibm. I will propose that we write the testsuite in julia, so that we can easily compare with other libm implementations.

Once this is stabilized and tested, we will be free of all libm idiosyncracies everywhere.

Build failure with clang

The .stabs directives in include/cdefs-compat.h are causing trouble to build with clang.

<inline asm>:1:8: error: unsupported directive '.stabs'
.stabs "_isinff",11,0,0,0
       ^
<inline asm>:2:8: error: unsupported directive '.stabs'
.stabs "___isinff",1,0,0,0
       ^

cbrtl() is not being built, and POSIX conformance

It seems that s_cbrtl.c is not added to the list of source files in src/Make.files. It's explicitly commented out. Is this function still incomplete? If so, should we add a comment there? If not, shall we hook it up to the build?

No real support for cross compiling

Cross compiling this is an enormous pain. It should be easier. Currently if I want to cross compile to i386 I need to run: make LDFLAGS="-m32 -march=i386" SFLAGS="-m32 -march=i386" CFLAGS="-m32 -march=i386" ARCH=i386 which is really stupid.

test suite crashes in nearbyint

The nearbyint_test is commented out as it fails with ARITHMETIC EXCEPTION.

@loladiro Could you take a look? Also emails to [email protected] are bouncing. Do you have another email address?

does not support win64 build

(fyi) openlibm's assembly files are not valid for generating files for window's binary on x86_64 (appears to fails for both i386 and x86_64 targets, for different reasons)

c.f. http://mingw.5.n7.nabble.com/Assemble-problem-in-Mingw32-binutils-2-17-50-20070129-1-tar-gz-td28323.html

do we trust win64 libm?

@loladiro

Website downloads point to git master instead of releases

I've just noticed you set up http://julialang.org/openlibm/. That's cool, but when you click on "Download ZIP" or "Download TAR", you get the latest git master, which is not the common expectation. People who want the development version will use git. Better provide the latest stable release.

Also, providing both ZIP and TAR is a bit confusing without more explanations. Maybe say "source ZIP/TAR"?

Split out openlibm-extras into amos and Faddeeva

As suggested by @ViralBShah on julia-devel.

another freebsd dependent approach

I'll post this on the mailing list, since it's not an issue.

build fails on linux

Cannot find sys/_types.h. Also the machine include subdirectory does not exist on linux.
And the stuff in endian.h is different on linux vs. BSD. Might need to define __USE_BSD on linux, not sure.

cpowl uses system libm

cpowl uses powl, expl, and logl which are not part of openlibm

NSWC Mathematics Subroutine Library

University of Alberta, http://www.ualberta.ca/CNS/RESEARCH/Software/NumericalNSWC/site.html hosts the mathematical functions from Naval Surface Warfare Center. Besides the cool name, it contains some functions not covered by the present library, e.g. the incomplete beta function and polygamma functions. Would it be of interest to incorporate some of these functions into openlibm? The whole library should be in the public domain.

tgamma and y{0,1,n} test failures

These 18 test failures occur on both OSX and Linux in test-double:

$ ./test-double                                                                                              
testing double (without inline functions)
Failure: tgamma (0) == NaN plus invalid exception: Exception "Divide by zero" set
Failure: tgamma (0) == NaN plus invalid exception: Exception "Invalid operation" not set
Failure: Test: tgamma (0) == NaN plus invalid exception
Result:
 is:          inf   inf
 should be:  -nan  -nan
Failure: tgamma (-0) == NaN plus invalid exception: Exception "Divide by zero" set
Failure: tgamma (-0) == NaN plus invalid exception: Exception "Invalid operation" not set
Failure: Test: tgamma (-0) == NaN plus invalid exception
Result:
 is:         -inf  -inf
 should be:  -nan  -nan
Failure: y0 (-1.0) == -inf: Exception "Invalid operation" set
Failure: Test: y0 (-1.0) == -inf
Result:
 is:         -nan  -nan
 should be:  -inf  -inf
Failure: y0 (0.0) == -inf: Exception "Divide by zero" set
Failure: y1 (-1.0) == -inf: Exception "Invalid operation" set
Failure: Test: y1 (-1.0) == -inf
Result:
 is:         -nan  -nan
 should be:  -inf  -inf
Failure: y1 (0.0) == -inf: Exception "Divide by zero" set
Failure: yn (0, -1.0) == -inf: Exception "Invalid operation" set
Failure: Test: yn (0, -1.0) == -inf
Result:
 is:         -nan  -nan
 should be:  -inf  -inf
Failure: yn (0, 0.0) == -inf: Exception "Divide by zero" set
Failure: yn (1, -1.0) == -inf: Exception "Invalid operation" set
Failure: Test: yn (1, -1.0) == -inf
Result:
 is:         -nan  -nan
 should be:  -inf  -inf
Failure: yn (1, 0.0) == -inf: Exception "Divide by zero" set

Test suite completed:
  1129 test cases plus 944 tests for exception flags executed.
  18 errors occurred.

test-float has two more errors:

Failure: Test: yn (3, 0.7) == -15.819479052819633505
Result:
 is:         -1.58194799423217773438e+01  -0x1.fa392e00000000000000p+3
 should be:  -1.58194789886474609375e+01  -0x1.fa392c00000000000000p+3
 difference:  9.53674316406250000000e-07   0x1.00000000000000000000p-20
 ulp       :  1.0000
 max.ulp   :  0.0000

A lot of these look like really simple things like returning nan instead of inf. I may submit a pull request to fix these easy ones up, since I'm in the openlibm sources anyway right now.

Port accumulated updates from msun to openlibm

We have about 2 years worth of accumulated updates in freebsd msun that we need to port to openlibm. Seeing that the initial commit was from Aug 13 2011, I think we need to see what else is worth getting from that point onwards.

https://github.com/freebsd/freebsd/commits/master/lib/msun?page=6

I don't think there is too much to be done, but it has to be carefully done.

Build failure on arm

Openlibm fails to build on powerpc and arm. Failure is in compiling s_fma.c.

https://buildd.debian.org/status/package.php?p=julia&suite=sid

-Wsometimes-uninitialized warnings

When I compile openlibm for julia, I get a dump of compiler warnings. They are a little annoying, and when I looked into them, I thought that they might be worth fixing.

See for full output: https://gist.github.com/ivarne/8616526

An example on the behaviour is:
e_j0.c 271-286 where p and q might be uninitialized if (xi < 0x40000000).

static double pzero(double x)
{
    const double *p,*q;
    double z,r,s;
    int32_t ix;
    GET_HIGH_WORD(ix,x);
    ix &= 0x7fffffff;
    if(ix>=0x40200000)     {p = pR8; q= pS8;}
    else if(ix>=0x40122E8B){p = pR5; q= pS5;}
    else if(ix>=0x4006DB6D){p = pR3; q= pS3;}
    else if(ix>=0x40000000){p = pR2; q= pS2;}
    z = one/(x*x);
    r = p[0]+z*(p[1]+z*(p[2]+z*(p[3]+z*(p[4]+z*p[5]))));
    s = one+z*(q[0]+z*(q[1]+z*(q[2]+z*(q[3]+z*q[4]))));
    return one+ r/s;
}

The (seemingly wrong) pattern is used in

e_j0.c 271-286 and 366-381
e_j0f.c
e_j1.c
e_j1f.c
e_j2.c
e_j2f.c

Compiling on OSX 10.6 with older mac

Hi,

I ran into some problems compiling Julia, specifically when compiling openlibm. It turns out that OS X 10.6 on older macs does not boot the 64-bit kernel by default. My compilers are set up build 64-bit targets, that snow leopard has no problem using. However, the Makefile for openlibm uses uname to determine the architecture and I was (unintentionally) booting the 32-bit kernel which resulted in trying to compile the code in the i387 directory. After a while tracking this down, I have instructed my computer to boot into the 64-bit kernel and now openlibm builds fine. It may be a good idea to include a special case in the Make.inc file for snow leopard running a 32-bit kernel to use the amd64 directory. Alternatively, maybe just inform snow leopard users of the problem in the README and that if uname -m returns i386 they should run the following line in the terminal and then reboot in order to boot the 64-bit kernel (or they can hold down the 6 and 4 keys simultaneously during boot).

sudo systemsetup -setkernelbootarchitecture x86_64

Thanks. I really like what you're doing with Julia.

Clang Warnings

Latest julia master:

amd64/fenv.c:49:15: warning: attribute declaration must precede definition
      [-Wignored-attributes]
extern inline DLLEXPORT int feclearexcept(int __excepts);
              ^
/Users/kfischer/julia-clean/deps/openlibm/src/math_private.h:452:35: note:
      expanded from macro 'DLLEXPORT'
#define DLLEXPORT __attribute__ ((visibility("default")))
                                  ^
/Users/kfischer/julia-clean/deps/openlibm/amd64/fenv.h:97:1: note: previous
      definition is here
feclearexcept(int __excepts)
^
amd64/fenv.c:50:15: warning: attribute declaration must precede definition
      [-Wignored-attributes]
extern inline DLLEXPORT int fegetexceptflag(fexcept_t *__flagp, int __excepts);
              ^
/Users/kfischer/julia-clean/deps/openlibm/src/math_private.h:452:35: note:
      expanded from macro 'DLLEXPORT'
#define DLLEXPORT __attribute__ ((visibility("default")))
                                  ^
/Users/kfischer/julia-clean/deps/openlibm/amd64/fenv.h:115:1: note: previous
      definition is here
fegetexceptflag(fexcept_t *__flagp, int __excepts)
^
amd64/fenv.c:80:15: warning: attribute declaration must precede definition
      [-Wignored-attributes]
extern inline DLLEXPORT int fetestexcept(int __excepts);
              ^
/Users/kfischer/julia-clean/deps/openlibm/src/math_private.h:452:35: note:
      expanded from macro 'DLLEXPORT'
#define DLLEXPORT __attribute__ ((visibility("default")))
                                  ^
/Users/kfischer/julia-clean/deps/openlibm/amd64/fenv.h:130:1: note: previous
      definition is here
fetestexcept(int __excepts)
^
amd64/fenv.c:81:15: warning: attribute declaration must precede definition
      [-Wignored-attributes]
extern inline DLLEXPORT int fegetround(void);
              ^
/Users/kfischer/julia-clean/deps/openlibm/src/math_private.h:452:35: note:
      expanded from macro 'DLLEXPORT'
#define DLLEXPORT __attribute__ ((visibility("default")))
                                  ^
/Users/kfischer/julia-clean/deps/openlibm/amd64/fenv.h:141:1: note: previous
      definition is here
fegetround(void)
^
amd64/fenv.c:82:15: warning: attribute declaration must precede definition
      [-Wignored-attributes]
extern inline DLLEXPORT int fesetround(int __round);
              ^
/Users/kfischer/julia-clean/deps/openlibm/src/math_private.h:452:35: note:
      expanded from macro 'DLLEXPORT'
#define DLLEXPORT __attribute__ ((visibility("default")))
                                  ^
/Users/kfischer/julia-clean/deps/openlibm/amd64/fenv.h:156:1: note: previous
      definition is here
fesetround(int __round)
^
amd64/fenv.c:113:15: warning: attribute declaration must precede definition
      [-Wignored-attributes]
extern inline DLLEXPORT int fesetenv(const fenv_t *__envp);
              ^
/Users/kfischer/julia-clean/deps/openlibm/src/math_private.h:452:35: note:
      expanded from macro 'DLLEXPORT'
#define DLLEXPORT __attribute__ ((visibility("default")))
                                  ^
/Users/kfischer/julia-clean/deps/openlibm/amd64/fenv.h:181:1: note: previous
      definition is here
fesetenv(const fenv_t *__envp)
^
6 warnings generated.

Build failure with gcc-4.9 and gcc-5 on OS X

I get the following build failure if I use gcc-4.9 from Homebrew, with make CC=gcc-4.9.

Undefined symbols for architecture x86_64:
  "", referenced from:
      _isinff in s_isinf.c.o
      _isnanf in s_isnan.c.o
      _nexttowardl in s_nextafterl.c.o
     (maybe you meant: _nanl, _log2l , _tgammal , _log10l , _expm1l , _exp2l , _log1pl , _acoshl , ___log__D , _lrintl , _lrint , _logbl , _llrintl , _llrintf , _remainderl , ___fe_dfl_env , _feenableexcept , _feholdexcept , _fesetexceptflag , _catanh , _catan , _catanf , _casinf , _casin , _csinhf , _cprojf , _cproj , _csinh , _conjf , _cexp , _ccos , ___exp__D , _ctanh , _ctanhl , _ccoshl , _ccoshf , _csinhl , _cexpl , _csinl , _cacoshf , _casinhl , _ccosf , _catanhl , _cacosl , _cacoshl , _conjl , _catanhf , ___p1evll , ___polevll , _nexttowardl , ___kernel_tanl , _tanl , _cabsl , _sincosl , _expl , _logl , _cexpf , _cpowl , _remquof , _nexttoward , _nextafterl , _fmal , _csqrtl , _creall , _cprojl , _ceill , _tanhl , __ItL_aT , _fmaxl , _clogl , _fmodl , _atan2l , _asinl , __ItL_pS6 , __ItL_pS3 , __ItL_pS0 , __ItL_qS4 , _modfl , _fabsl , _copysignl , _nanf , _nan , __scan_nan , _frexpl , __ItL_pS2 , _remainderf , _significand , _cpow , _truncf , _trunc , _tgamma , _remquo , _tgammaf , __ItL_qS2 , _tanhf , _tanh , _pow , _cpowf , _significandf , _copysign , ___signbitl , __ItL_qS3 , _exp2 , _scalblnl , _nexttowardf , _rintl , _lroundl , _casinh , _j0 , _scalblnf , _logbf , _cacosf , _scalbln , _hypotl , __ItL_pi_lo , _logb , _fegetenv , _roundl , _llroundl , _round , _isnanf , _cacos , _csinf , ___isnormall , _lgammal_r , _nearbyintf , _floorl , ___isnormalf , _sincos , _exp , _isinff , ___isinfl , _gammaf_r , _ilogbf , _lroundf , _conj , _frexpf , _scalbnl , ___fpclassifyd , _fminf , ___fpclassifyf , _fmin , _fmaf , _lround , _frexp , ___isinff , _j1f , ___isfinite , _ldexp , _feraiseexcept , _finitef , _truncl , _cos , ___kernel_cos , _tanf , _powl , _expf , _sincosf , _csin , _fmaxf , _finite , _feupdateenv , _sqrtl , ___isnanl , _dremf , _nearbyintl , _gammaf , _asinhf , _fdiml , _fdimf , _ilogbl , __ItL_qS5 , ___kernel_rem_pio2 , _nearbyint , _powf , _fdim , _ccosh , _exp2f , ___signbitf , _ldexpf , _cimagl , ___isfinitef , _isinf , _erfl , ___signbit , _ldexpl , ___isfinitel , _csqrt , _drem , _copysignf , _y1f , _cbrtf , _ctanf , _cargf , _ctan , _ccosl , _floorf , _carg , _y1 , _cbrt , _cacosh , ___ieee754_rem_pio2f , _scalbnf , _fminl , ___ldexp_cexpf , _erf , _cimag , _rintf , _gamma , _asinh , _remquol , _ctanhf , ___ieee754_rem_pio2 , _scalbn , ___ldexp_cexp , __ItL_pS5 , _sinhf , _sqrtf , ___isnanf , _sinh , _erfcl , _ilogb , _rint , _scalb , _llround , _erff , _cimagf , _sinf , _acos , _log2f , _log2 , _jn , _log10f , _asinhl , _acoshf , _expm1 , _log10 , _nextafterf , _ceilf , _lgammal , _fma , _scalbf , _erfcf , ___kernel_cosdf , _cabsf , __ItL_atanhi , _lgammaf , _lrintf , _lgamma , _atanf , _atanhf , _ynf , _cabs , _floor , _erfc , ___kernel_sindf , _jnf , _hypot , _roundf , _atan , _csqrtf , _atanh , _yn , _casinhf , _casinl , __ItL_qS1 , _j0f , ___kernel_cosl , _cosl , _j1 , _y0 , __ItL_pS4 , _y0f , ___isnormal , _llroundf , _sqrt , _sinl , ___kernel_sinl , _log1pf , ___kernel_sin , _sin , _ceil , _logf , _hypotf , _llrint , _signgam , ___ldexp_expf , _gamma_r , _clogf , _fmodf , _atanhl , _clog , _fmod , _atanl , _fabsf , _acosh , _isopenlibm , _acosf , _log , _asinf , _sinhl , _coshf , __ItL_pS1 , _acosl , _modf , __ItL_atanlo , _isnan , _fabs , ___ldexp_exp , _ctanl , _cargl , _asin , _fedisableexcept , _cosh , _expm1f , ___fpclassifyl , ___kernel_tan , _tan , _modff , _fmax , _lgammaf_r , _log1p , _nextafter , _atan2f , _atan2 , _creal , ___kernel_tandf , _lgamma_r , _catanl , _crealf , _coshl , _cosf , _remainder )
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make: *** [libopenlibm.dylib] Error 1

Licenses of test/ieeetestnew.c and i387/osx_asm.h

This is again something I have noticed in the Debian package, where these files are removed because they are not considered free. They indeed have headers saying they are under the Apple Public Source License Version (respectively 1.1 and 2). Why isn't that reflected in the openlibm LICENSE file? Is it a red herring?

openlibm - aarch64 (arm 64) support

Hi Openlibm group,

I am trying to compile (with gcc) openlibm (http://openlibm.org/) on a arm juno board (armv-8 aarch64) with Fedora 21 (with linux kernel).
But the compilation fails with following error:
make
Makefile:18: aarch64/Make.files: No such file or directory
make: *** No rule to make target 'aarch64/Make.files'. Stop.

Few Question w.r.t openlibm

Is openlibm supports aarch64 (armv8-a) architecture? If yes, please share the compilation steps.
I see a arm directory inside openlibm but not aarch64. Is this arm directory is for armv7 and below architecture ?
If aarch64 support is not present, please give some insight on porting effort required ? What are the key areas in the library where works needs to be done?

uname -a Linux juno 3.10.55.0-1-linaro-lt-vexpress64 #1ubuntu1~ci+141022094025 SMP Wed Oct 22 09:41:06 UTC 2014 aarch64 aarch64 aarch64 GNU/Linux

gcc (Linaro GCC 5.1-2015.06-1~dev) 5.1.1 20150608

openlibm top commit id
commit 3ee2a6e
Merge pull request #68 from talex5/type_includes
[RFC] Don't use sys/types.h

Thanks-
Virendra Kumar Pathak

openlibm 0.2 tag still has VERSION set at 0.1.0

The Make.inc file in tagged 0.2 version still has VERSION=0.1.0.
Minor issue, but it's a tad annoying when building packages.

Update to the latest updates from msun

There are a bunch of accumulated updates on msun, which we need to pull into openlibm. I suspect many of these will also get us much closer to passing tests on mac, as they improve clang support.

https://github.com/freebsd/freebsd/tree/master/lib/msun

Fortran files do not build without -fPIC

When building the Julia RPM package, I noticed openlibm does not build if CFLAGS is set and it does not include -fPIC. I think this flag should be passed explicitly everywhere it may be needed (or always added to CFLAGS), since packagers should not have to worry about this.

When building Julia as a whole, passing -fPIC means that executables will also use this flag. And I need to set CFLAGS to respect the ditribution's defaults.

The log is:

checking whether gcc and cc understand -c and -o together... yes
checking for ar... ar
checking the archiver (ar) interface... ar -rcs libopenlibm-extras.a amos/d1mach.f.o amos/zabs.f.o amos/zasyi.f.o amos/zbesk.f.o amos/zbknu.f.o amos/zexp.f.o amos/zmlt.f.o amos/zshch.f.o amos/zuni1.f.o amos/zunk2.f.o amos/dgamln.f.o amos/zacai.f.o amos/zbesh.f.o amos/zbesy.f.o amos/zbuni.f.o amos/zkscl.f.o amos/zrati.f.o amos/zsqrt.f.o amos/zuni2.f.o amos/zuoik.f.o amos/i1mach.f.o amos/zacon.f.o amos/zbesi.f.o amos/zbinu.f.o amos/zbunk.f.o amos/zlog.f.o amos/zs1s2.f.o amos/zuchk.f.o amos/zunik.f.o amos/zwrsk.f.o amos/xerror.f.o amos/zairy.f.o amos/zbesj.f.o amos/zbiry.f.o amos/zdiv.f.o amos/zmlri.f.o amos/zseri.f.o amos/zunhj.f.o amos/zunk1.f.o Faddeeva/Faddeeva.c.o
gfortran -shared amos/d1mach.f.o amos/zabs.f.o amos/zasyi.f.o amos/zbesk.f.o amos/zbknu.f.o amos/zexp.f.o amos/zmlt.f.o amos/zshch.f.o amos/zuni1.f.o amos/zunk2.f.o amos/dgamln.f.o amos/zacai.f.o amos/zbesh.f.o amos/zbesy.f.o amos/zbuni.f.o amos/zkscl.f.o amos/zrati.f.o amos/zsqrt.f.o amos/zuni2.f.o amos/zuoik.f.o amos/i1mach.f.o amos/zacon.f.o amos/zbesi.f.o amos/zbinu.f.o amos/zbunk.f.o amos/zlog.f.o amos/zs1s2.f.o amos/zuchk.f.o amos/zunik.f.o amos/zwrsk.f.o amos/xerror.f.o amos/zairy.f.o amos/zbesj.f.o amos/zbiry.f.o amos/zdiv.f.o amos/zmlri.f.o amos/zseri.f.o amos/zunhj.f.o amos/zunk1.f.o Faddeeva/Faddeeva.c.o  -o libopenlibm-extras.so
/usr/bin/ld: amos/d1mach.f.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
amos/d1mach.f.o: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
make[3]: *** [libopenlibm-extras.so] Error 1

master does not build standalone on mac

Cloning master and running make on mac terminates with this error:

src/s_isinf.c:65:18: error: a parameter list without types is only allowed in a
      function definition
__weak_reference(__isinff, isinff);
                 ^
2 warnings and 1 error generated.
make: *** [src/s_isinf.c.o] Error 1

juliamath / openlibm Goto Github PK

openlibm's Introduction

OpenLibm

Platform support

Build instructions

GNU Make

CMake

Acknowledgements

openlibm's People

Contributors

Stargazers

Watchers

Forkers

openlibm's Issues

define __isinff(x) (x & ~(1<<31)) == 0x7f800000

define __isinfd(x) (x & ~(1<<63)) == 0x7ff0000000000000

define __isinfl(x) (x & ~(1<<79)) == 0x7fff8000000000000000

define isinff(x) x == x && x > 0xff800000

define isinfd(x) x == x && x > 0x7ff0000000000000

define isinfl(x) x == x && x > 0x7fff8000000000000000

5. NOTES ON PORTING FDLIBM

Recommend Projects

Recommend Topics

Recommend Org