long double functions, that are identical to double functions, usually
define themselves as weak references to their double counterpart.
However, the piece of assembler written for that produces
.equ <name>l, <name>
but on SuperH C-exported symbols have leading underscores. This commit
adds an SH3 exception to use instead
.equ _<name>l, _<name>
which fixes a number of long double functions.
The implementation of `fesetenv` cannot be portable, as the value of
`FE_DFL_ENV` differs between platforms. On FreeBSD, it is a actual
environment. With glibc however, it's a sentinel -1 handled in the
implementation of its floating point functions.
With openlibm based on FreeBSD's libm, it assumes `FE_DFL_ENV` to be an
actual environment. That assumption breaks using code that was compiled
against glibc, e.g., `libcuda`:
```
Thread 1 "julia-debug" received signal SIGSEGV, Segmentation fault.
0x00007ffff7b855d0 in fesetenv () from /home/tim/Julia/julia/build/release/usr/bin/../lib/libopenlibm.so
(gdb) bt
```
This reverts commit 5a27b4c0c0.
Fixes https://github.com/JuliaLang/julia/issues/38427.
My previous Apple Silicon build went through, so I thought it already
worked, but it turns out it accidentally built an armv7 build instead.
This actually fixes the Apple Silicon build. One thing to note in
particular is that on Apple Silicong `long double` is the same as
`double` while on Linux `long double` is a 128 bit double-double
format.
Co-authored-by: Elliot Saba <staticfloat@gmail.com>
Win32 has been using a hack to switch the `fenv` functions from `static`
to `DLLEXPORT`, we apply that hack to all platforms that do not use a
host `fenv.h`.
__strong_alias is an ELF feature that is not available on Darwin/MachO.
We have openlibm_strong_reference to paper over these differences,
but we weren't using it consistently. In particular, we were still
using it to define long double -> double aliases on platforms where
these are the same type (e.g. aarch64). This didn't used to matter,
because the only such platform we supported was always Linux and
thus ELF. This patch fixes these instances thus fixing the build
on Apple Silicon.
On x86_64, openlibm_fenv.h is silently coupled to openlibm_complex.h due to the inclusion of math_private.h inside of openlibm_fenv_amd64.h. The math_private.h header was included to gain access to the OLM_DLLEXPORT macro. However, this macro is redefined, since it is originally defined in openlibm_math.h. This inclusion also exposes math_private.h to public clients, which is undesirable.
Instead, a standalone header is created to contain the OLM_DLLEXPORT definition. This header is used included in the appropriate files. openlibm_fenv_amd64.h is no longer coupled to math_private.h.
