`fma` calls the system libm, not Julia's openlibm

[eschnett]

I am tracking down a test failure where fma returns a wrong result. This is a 64-bit Intel Linux system with glibc 2.12 installed.

code_native tells me that fma expands to a libcall on this system (as should be), and also tells me the address of this fma function, but without giving it a name. /proc/*/maps tells me that this address is part of a range where /lib64/libm-2.12.so is mapped. That is, Julia's fma call goes to the system libm, not to Julia's openlibm.

The reason is that we expand Julia's fma to an LLVM intrinsic, and the libcall is then generated by LLVM since there is no fma machine instruction available. LLVM chooses to call libm.

I suggest to check whether the system has an fma instruction when expanding Julia's fma function, and if not, expanding it to a call to openlibm instead of an LLVM intrinsic. This requires #9855 to be available.

This issue may be related to #9847.

[tkelman]

I saw a similar fma-related test failure inside a Docker container of Centos 5 using the devtoolset, but the host system on Ubuntu 14.04 didn't reproduce.

[eschnett]

The failure should depend on the libc version.

[vtjnash]

you should be able to set UNTRUSTED_SYSTEM_LIBM if you want it to be much more likely that all libm calls in julia end up getting redirected to openlibm (this is necessary on windows, for example)

[eschnett]

Who looks at this variable -- Julia or LLVM? How does LLVM know about openlibm?

[vtjnash]

it's a makefile variable

[tkelman]

It statically links libopenlibm.a into libjulia the julia executable, last time I looked at it

[ViralBShah]

The real solution is for openlibm to have a Makefile variable that allows olm_ prefixes.

[tkelman]

Probably a good idea. We should be able to apply the same method I used for OpenBLAS.

[nalimilan]

But that won't fix things for distribution packages. :-/ Or should we ship both standard names and names with the olm_ prefix?

[eschnett]

Setting UNTRUSTED_SYSTEM_LIBM=1 did not help. The resulting julia executable does have fma linked in statically, but LLVM still chooses a dynamically linked in libm at run time.

[vtjnash]

I'm not sure how that would happen, unless libLLVM is also dynamically linked. You can't both distrust your system libm but trust your system llvm.

[eschnett]

I installed LLVM 3.5.1 manually. Yes, it's linked dynamically -- good point.