search for: __acos_finite

...libc++ / ... symbol so I assumed that it was not necessary to specifically link against libm where these __finite symbols reside: $ nm -D /usr/lib/libm.so.6 | grep finite 0000000000050540 T __acosf128_finite at GLIBC_2.26 0000000000042f70 T __acosf_finite at GLIBC_2.15 0000000000026940 i __acos_finite at GLIBC_2.15 0000000000051000 T __acoshf128_finite at GLIBC_2.26 0000000000043240 T __acoshf_finite at GLIBC_2.15 ) but maybe it needs some help on that regard ? Thanks for your quick answer, Jean-Michaël On Mon, Oct 5, 2020 at 7:53 PM Lang Hames <lhames at gmail.com> wrote: > Hi...

...essary to specifically link >> against libm where these __finite symbols reside: >> >> $ nm -D /usr/lib/libm.so.6 | grep finite >> 0000000000050540 T __acosf128_finite at GLIBC_2.26 >> 0000000000042f70 T __acosf_finite at GLIBC_2.15 >> 0000000000026940 i __acos_finite at GLIBC_2.15 >> 0000000000051000 T __acoshf128_finite at GLIBC_2.26 >> 0000000000043240 T __acoshf_finite at GLIBC_2.15 >> ) >> but maybe it needs some help on that regard ? >> >> Thanks for your quick answer, >> >> Jean-Michaël >> >>...

Hello, when building code with -Ofast -ffinite-math-only -ffast-math, clang generates calls to "finite" variants of math functions. This has been the source of a fair amount of issues in a "normal", non-JIT pipeline, which seem to have been fixed over time - a simple fix being recompiling the target app against the new glibc. - https://bugs.llvm.org/show_bug.cgi?id=44842 -

...onEv _ZdlPvRKSt9nothrow_t 1 _ZN3lld3elf22SymbolTableBaseSection17postThunkContentsEv _ZdlPvRKSt9nothrow_t 1 generic_start_main __pow_finite 1 generic_start_main __log_finite 1 generic_start_main __exp_finite 1 generic_start_main __atan2_finite 1 generic_start_main __asin_finite 1 generic_start_main __acos_finite 1 generic_start_main tan 1 generic_start_main __sin 1 generic_start_main __cos 1 generic_start_main __floor 1 generic_start_main __ceil 1 generic_start_main atan 1 __libc_csu_init _GLOBAL__sub_I_Verifier.cpp 1 _ZN4llvm12PassRegistryD2Ev _ZN4llvm3sys11RWMutexImplD2Ev 1 _ZN4llvm14object_creatorINS_12...

A rebased version of the lld patch is attached. Cheers, Rafael On 31 July 2017 at 15:11, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > Tobias Edler von Koch <tobias at codeaurora.org> writes: > >> Hi Rafael, >> >> On 07/31/2017 04:20 PM, Rafael Avila de Espindola via llvm-dev wrote: >>> However, do we need to start with