#
266314 |
|
17-May-2014 |
ian |
MFC 262989, 263210, 263230, 263231, 263239, 263242, 263243,
Export _libc_arm_fpu_present as a private symbol to be used by other system libraries, for example libm.
On armv6 access both the softfloat and, when available, the vfp to get and set the floating-point environment.
Build fenv-vfp.c with the softfp float abi. Without this gcc generates an incorrect assembly file that doesn't allow for vfp instructions.
Only build the vfp/softfp switching code on armv6 as we don't support vfp on anything earlier than this. This should fix the armeb and arm builds when using gcc.
Add an optimised version of the float and double helper functions.
|
#
230367 |
|
20-Jan-2012 |
das |
Don't inline fenv.h functions on arm for now. Inlining makes sense: the function bodies require only 2 to 10 instructions. However, it leads to application binaries that refer to a private ABI, namely, the softfloat innards in libc. This could complicate future changes in the implementation of the floating-point emulation layer, so it seems best to have programs refer to the official fe* entry points in libm.
|
#
226218 |
|
10-Oct-2011 |
das |
Provide external definitions of all of the standardized functions in fenv.h that are currently inlined.
The definitions are provided in fenv.c via 'extern inline' declaractions. This assumes the compiler handles 'extern inline' as specified in C99, which has been true under FreeBSD since 8.0.
The goal is to eventually remove the 'static' keyword from the inline definitions in fenv.h, so that non-inlined references all wind up pointing to the same external definition like they're supposed to. I am deferring the second step to provide a window where newly-compiled apps will still link against old math libraries. (This isn't supported, but there's no need to cause undue breakage.)
Reviewed by: stefanf, bde
|