Fix invalid assembly directive caught by clang

Similar to the x86_64 changes a while back

Blanket rename DLLEXPORT->OLM_DLLEXPORT

Use quotes instead of <> with #include for private headers

Cleanup bsd_cdefs.h, merge i387 and amd64 duplicate files

Most macros were not actually used. This gets rid of warnings when
building on Linux.

Change some #ifdefs to be different than the system ones.

Fix fpgetprec and fpsetprec.

Use i386 ieeefp.h

Enable stack protection for all ELFs, not only __linux__

Build on GNU/kfreeBSD and GNU/Hurd
Use __GLIBC__ instead of __linux
Simplify Make.inc as per JuliaLang/openspecfun@e91925a

Remove the non-standard finite() function.

Remove the non-standard significand() function.

Remove unused Symbol.map files.

Remove $ARCH/openlibm_fenv.h.

It seems I accidentally copied these headers twice in
d07820351bed7d16f1f0a1ae0596a2e2b6f50aaf. We should only have them in
include/.

Move public headers into include/ and private headers into src/.

While there, also modify the install target. We should make sure to
install all openlibm*.h headers. There is still some work to be d

Move public headers into include/ and private headers into src/.

While there, also modify the install target. We should make sure to
install all openlibm*.h headers. There is still some work to be done:
openlibm_fenv_*.h still depends on some additional bits. I'd propose
that we eventually create an include/openlibm_cdefs.h that contains all
of the macros we need.

show more ...

Rename the fenv headers.

I guess the idea would be to eventually also install all of the
openlibm*.h headers, instead of just openlibm.h. Make openlibm_fenv.h
suitable for this purpose by moving all

Rename the fenv headers.

I guess the idea would be to eventually also install all of the
openlibm*.h headers, instead of just openlibm.h. Make openlibm_fenv.h
suitable for this purpose by moving all of the $ARCH/fenv.h headers next
to it.

We actually need this change to make OPENLIBM_USE_HOST_FENV_H work.
Right now it's still broken, because the "#include <fenv.h>" performed
by openlibm_fenv.h still pulls in $ARCH/fenv.h as $ARCH/ is added to the
compiler include path.

show more ...

Remove weak reference construct from fenv code.

I grepped through the FreeBSD source tree and for me, it seems to be
totally unclear why these two specific functions are weak references.
Such a cons

Remove weak reference construct from fenv code.

I grepped through the FreeBSD source tree and for me, it seems to be
totally unclear why these two specific functions are weak references.
Such a construct is commonly used by FreeBSD's threading library
(libthr) to override certain functions, but I can't find any traces of
that.

Just use the function name directly. This fixes a compiler warning as
well (-Wmissing-prototypes).

show more ...

Rename include/fenv.h to <openlibm_fenv.h>.

OpenLibm has an implementation of fenv.h internally. This may be
problematic in case you want it to build against the host system's
implementation, as it

Rename include/fenv.h to <openlibm_fenv.h>.

OpenLibm has an implementation of fenv.h internally. This may be
problematic in case you want it to build against the host system's
implementation, as it would require you to somehow take the fenv.h file
out of the compiler search path.

Simply use a different naming scheme, similar to openlibm.h and
openlibm_complex.h. If we want to build against the host's fenv.h, we
can simply add an '#include <fenv.h>' from within this header.

show more ...

don't use system machine/npx.h on OS X either, since it may not exists and isn't necessary

work around msvc bug where .model must be on its own line or it forgets about it

add win64 compat definitions also

add more windows compatibility definitions

normalize __WIN32__ to _WIN32, which is defined by all Windows compilers

Enable stack protection in all .S files

Hardware stack protection is required by most distributions.
See https://wiki.gentoo.org/wiki/Project:Hardened/GNU_stack_quickstart

provide fenv functions on windows

add DLLEXPORT to i387 and amd64 assembly (win32 target) and ld80/ld128 files