The next NDK to take these headers only supports API 21 and later, so
clean up some of the trivial cruft.
This doesn't include the remaining "legacy inlines", since they're a bit
more complicated. I'll remove those in later changes.
Test: treehugger
Change-Id: I94c32f6393dd3ae831165917303ea591222baa0d
These cause great confusion, so explicitly point out that apps can't use
one, and probably want the other.
Bug: https://github.com/android/ndk/issues/1255
Test: N/A
Change-Id: I287e820dc45a8446e3c72c9a2e4007db76828e3b
Although the NDK ABI for x86 doesn't include SSE4.1, it's needed for
roundss/roundsd, and we've used that (via hand-written assembler) in the
x86 libm since Android M. We've recently switched to using compiler
builtins to generate the assembler instead, and without allowing the
compiler to use SSE4.1, it can't (resulting in infinite recursion as
these functions defer to themselves for an answer).
Given that the x86 libm.so has required SSE4.1 for 8 years at this
point without anyone noticing, let alone caring, let's just retain the
status quo rather.
(Despite the fact that this caused boot failures for cf_x86, I didn't
notice when testing the 32-bit libm.so from a cf_x86_64 build because our
x86-64 ABI *does* include SSE4.1, and the BoardConfig.mk for cf_x86_64
explicitly chooses "silvermont" as the 32-bit cpu variant, implicitly
enabling SSE4.1.)
Test: llvm-objdump -d on a cf_x86 build
Change-Id: I9392d3699057fcca96677de52f8d36d377b1719a
armv8 arm32 has a single instruction for the floor() family, but armv7
arm32 doesn't. Play stupid preprocessor and namespace tricks to get
the best of both worlds (using __ARM_ARCH in code is less awkward than
trying to do similar with armv7_a and armv7_a_neon in the build system).
Bug: http://b/268267713
Test: llvm-objdump -d
Change-Id: I2a4bef6e6caa49092810f53eb7bf6ea46237743f
The gwp_asan_integration.malloc_tests_under_torture test fails
when trying to run the malloc.zeroed* tests. So skip these
tests in that config.
Bug: 267386540
Test: All tests pass in hwasan and normal config.
Change-Id: I8edce28ee21eeecbcc9afb7db4ffdb6371a914b0
It looks like the only functions current clang can't do are the lrint
family. Everything else looks good, and the fact that clang has builtins
means we shouldn't normally see calls to any of these functions anyway.
Test: llvm-objdump
Change-Id: I65b4da96b6c9b10f01cb54a7ebd1de5934ba4488
These are system calls where the "good" names are camped by
implementations that only work for 16-bit ids, and you need to say "32"
on LP32 to get sensible behavior.
Noticed when disabling CONFIG_UID16 in the kernel.
Bug: http://b/266732373
Test: llvm-objdump -d
Change-Id: Ib1b5822b030c4f86df755b129ec7b435a7f77cd3
