These are obsolete aliases for equally obsolete functions, but apps built
with old versions of the NDK might still be emitting references to them.
Bug: N/A
Test: ran tests
Change-Id: I6eab910e3cd4d322604167799e83b5b7411c04c3
These are still needed for backwards compatibility with code built by old
versions of the NDK, but we don't need to pollute the headers with them.
Also lose the hand-written code for these. The compiler-generated code
is either the same or better, and no new code is calling these functions
anyway.
Bug: N/A
Test: ran tests
Change-Id: Ib01ad9805034433e0105aec882608cc8e6526f78
We can cut a lot of stuff out of the NDK's libandroid_support with this,
and reduce unnecessary relocations for all LP32 code. LP64 code should
be unaffected.
Bug: https://issuetracker.google.com/64450768
Bug: https://github.com/android-ndk/ndk/issues/507
Test: ran tests, plus manual readelf on the _test.o files
Change-Id: I3de6015921195304ea9c829ef31665cd34664066
sincos and sincosf are being tested more thoroughly with a table of data,
but there's nothing equivalent for sincosl.
Test: ran the tests, obviously.
Change-Id: I5b4b22b73cad9b0030549de2e2ed2a0e38648806
This patch adds more tests for math functions to address coverage
issue of math functions discussed in:
https://android-review.googlesource.com/#/c/49653/https://android-review.googlesource.com/#/c/94780/
These are data sets used in regression tests for the Intel the math library (libm). They were collected over a long period of testing various libm implementations.
The data sets contain function specific data (special and corner cases such as +/-0, maximum/minimum normalized numbers, +/-infinity, QNaN/SNaN, maximum/minimum denormal numbers, arguments that would produce close to overflow/underflow results, known hard-to-round cases, etc), implementation specific data (arguments close to table look-up values for different polynomial approximations, worst cases for range reduction algorithms) and other data with interesting bit patterns.
The reference values are computed with Maple and were converted into hexadecimal format.
Change-Id: I7177c282937369eae98f25d02134e4fc3beadde8
Signed-off-by: Jingwei Zhang <jingwei.zhang@intel.com>
Signed-off-by: Mingwei Shi <mingwei.shi@intel.com>
At the moment our libm is only good enough for a 1 ulp bound on these tests,
but that's better than the 4 ulp bound you get from gtest by default.
I'm not really happy with the multiple structures and corresponding functions,
but at least they mean there's no duplication in the tests themselves, and it
should be easy enough for us to make further improvements in future.
Change-Id: I004e12970332e1d9531721361d6c34f908cfcecc
Upstream has implemented lgammal/lgammal_r for ld128, and fixed the
sign problem we reported with all the lgamma*_r functions and -0.
Bug: 17471883
Change-Id: Ibb175d9cab67efae75f1010796fd44c9ba6ce4fc
From C99 standard: “The nextafter functions determine the next representable value, in the type of the function,
after x in the direction of y, where x and y are first converted to the type of the function”.
The next representable value of 0.0 in direction of -1.0 is -4.9406564584124654e-324, not 0.0.
Similar thing holds for nextafterf, nextafterl, nexttowardf, nexttoward, and nexttowardl.
The tests pass either way, since the error is within the tolerance, but how it is written is wrong.
Change-Id: I1338eeffe3de8031a48f46e1b07146bc07dc2f0a
Signed-off-by: Jingwei Zhang <jingwei.zhang@intel.com>
Signed-off-by: Mingwei Shi <mingwei.shi@intel.com>
Enable the -std=gnu++11 flag for libstdc++ static and
dynamic libs.
ScopeGuard uses DISABLE_ macros instead of '= delete';
Change-Id: I07e21b306f95fffd49345f7fa136cfdac61e0225
Reported on the OpenBSD list, but we already had the fix for one from FreeBSD,
and I think the other only affected ld80 anyway. Worth having tests thuogh.
Change-Id: Ic4bbeb2384fd578a3ef13e4907be83deda50815f
I've reported the wcsftime bug upstream, but we really just want to use -D
to ensure the buggy code isn't built. (I've also brought our strftime a bit
closer to upstream now we have the right define.)
I don't think upstream is likely to fix all their sign-compare and
uninitialized warnings, so let's just silence them.
As for libm, again upstream isn't likely to fix all their warnings, and
silencing those made the ones that were our fault stand out. I've fixed
our <math.h> to fix the warnings caused by our lack of definitions for
the non-imprecise long-double functions. I checked the C99 standard, and
all these functions are there.
Change-Id: Iee8e1182c1db375058fb2c451eceb212bab47a37
- promoted IEEEld2bits to fpmath since most of the where the same for
diffrent archs
- removed _fpmath
- reinstated weak_references
- moved isfinite and isnormal to libc
- clean up fake_long_doubles
- clean up some useless ifdefs
- added missing nexttoward* tests
Bug: 14134235
Change-Id: I95639c4885653fe47fd7dc0570ee5bb3389bbc6b
Also move isinf and isnan into libc like everyone else.
Also move fpclassify to libc like the BSDs (but unlike glibc). We need
this to be able to upgrade our float/double/long double parsing to gdtoa.
Also add some missing aliases. We now have all of:
isnan, __isnan, isnanf, __isnanf, isnanl, __isnanl,
isinf, __isinf, isinff, __isinff, isinfl, __isinfl,
__fpclassify, __fpclassifyd, __fpclassifyf, __fpclassifyl.
Bug: 13469877
Change-Id: I407ffbac06c765a6c5fffda8106c37d7db04f27d
* reworked amd64/_fpmath.h and arm64/_fpmath.h to support 128-bit long
doubles.
* improved tests to cover long double cases
* made modfl an alias for LP32
Tests pass on x86, x86_64, arm, arm64 and mips.
Bug: 12921273
Change-Id: Ibe39acde57972447a8950fa45b1e702acc68ebeb
Turns out stlport isn't broken. <cmath> (included
transitively via gtest in our case) is not required
to make C99 math macros (like signbit) available, nor is
it required to preserve them if they're already defined.
It is only required to make the equivalent functions in
namespace std available.
I couldn't find any documentation of required behaviour for
programs that include both <math.h> and <cmath>.
I've verified experimentally that llvm's libc++ and gnu
stl behave the same as stlport.
bug: 12935307
Change-Id: I9dc5cc0fd9f4f259abc8eefb280177cdd092a94b
In order to be able to generate a list of tests for cts, the same set of
tests must exist across all platforms. This CL adds empty tests where a
test was conditionally compiled out.
This CL creates a single library libBionicTests that includes all of
the tests found in bionic-unit-tests-static.
Also fix a few missing include files in some test files.
Tested by running and compiling the tests for every platform and
verifying the same number of tests are on each platform.
Change-Id: I9989d4bfebb0f9c409a0ce7e87169299eac605a2
This brings us up to date with FreeBSD HEAD, fixes various bugs, unifies
the set of functions we support on ARM, MIPS, and x86, fixes "long double",
adds ISO C99 support, and adds basic unit tests.
It turns out that our "long double" functions have always been broken
for non-normal numbers. This patch fixes that by not using the upstream
implementations and just forwarding to the regular "double" implementation
instead (since "long double" on Android is just "double" anyway, which is
what BSD doesn't support).
All the tests pass on ARM, MIPS, and x86, plus glibc on x86-64.
Bug: 3169850
Bug: 8012787
Bug: https://code.google.com/p/android/issues/detail?id=6697
Change-Id: If0c343030959c24bfc50d4d21c9530052c581837
