mirror of
git://git.musl-libc.org/musl
synced 2024-12-15 11:15:07 +00:00
4918c2bb20
it turns out that __SOFTFP__ does not indicate the ABI in use but rather that fpu instructions are not to be used at all. this is specified in ARM's documentation so I'm unclear on how I previously got the wrong idea. unfortunately, this resulted in the 0.9.12 release producing a dynamic linker with the wrong name. fortunately, there do not yet seem to be any public toolchain builds using the wrong name. the __ARM_PCS_VFP macro does not seem to be official from ARM, and in fact it was missing from the very earliest gcc versions (around 4.5.x) that added -mfloat-abi=hard. it would be possible on such versions to perform some ugly linker-based tests instead in hopes that the linker will reject ABI-mismatching object files, if there is demand for supporting such versions. I would probably prefer to document which versions are broken and warn users to manually add -D__ARM_PCS_VFP if using such a version. there's definitely an argument to be made that the fenv macros should be exposed even in -mfloat-abi=softfp mode. for now, I have chosen not to expose them in this case, since the math library will not necessarily have the capability to raise exceptions (it depends on the CFLAGS used to compile it), and since exceptions are officially excluded from the ARM EABI, which the plain "arm" arch aims to follow.
24 lines
476 B
C
24 lines
476 B
C
#ifndef __ARM_PCS_VFP
|
|
#define FE_ALL_EXCEPT 0
|
|
#define FE_TONEAREST 0
|
|
#else
|
|
#define FE_INVALID 1
|
|
#define FE_DIVBYZERO 2
|
|
#define FE_OVERFLOW 4
|
|
#define FE_UNDERFLOW 8
|
|
#define FE_INEXACT 16
|
|
#define FE_ALL_EXCEPT 31
|
|
#define FE_TONEAREST 0
|
|
#define FE_DOWNWARD 0x800000
|
|
#define FE_UPWARD 0x400000
|
|
#define FE_TOWARDZERO 0xc00000
|
|
#endif
|
|
|
|
typedef unsigned long fexcept_t;
|
|
|
|
typedef struct {
|
|
unsigned long __cw;
|
|
} fenv_t;
|
|
|
|
#define FE_DFL_ENV ((const fenv_t *) -1)
|