Those flags were used to suppress ABI tidy errors, but by now are not in
use anymore and can safely be removed.
Bug: 156513478
Change-Id: Ibc9625d139f933e48ebb4ddebe70d424f6231f3f
Signed-off-by: Matthias Maennich <maennich@google.com>
These are the same function for machines with binary floats (that is:
all machines), but ldexp() is in libc rather than libm, so we can't just
use an alias.
We were using this duplicate copy of the code, but upstream FreeBSD has
removed it, and I'd prefer to do the same.
Longer term, we should just move all of libm into libc (but keep an
empty libm for compatibility), but this is probably easier for now.
Test: treehugger
Change-Id: I1a1d6d4f1771316f791ad59c714a3a65aedefc81
More interesting changes to come, but there's enough of this noise I'm
separating it out...
Test: treehugger
Change-Id: I0efc0ac860a147112369df7561ee48a92a2a5e84
Discussion of this during my recent minor cleanup convinced me that we
should just remove __RENAME_LDBL. There's no obvious benefit to being
able to build something for 32-bit if you can't build the same code for
64-bit, given that most new hardware (and entire verticals such as Auto)
are 64-bit-only, and the Play Store requires any app with 32-bit code to
also ship 64-bit code.
Test: treehugger
Change-Id: I1c5503b968ca66925d7bd125bd3630c41ec1bfd0
Bazel doesn't like it when modules produce files with the same name
as the module itself, and gives warnings.
Rename either the module or file in this case so that the file has
an extension and the module doesn't.
Bug: 198619163
Test: m nothing
Change-Id: Ic4592b06f575496ffd54ac75cb4d682118b29d93
This completes the set, and gets riscv64 to parity with arm64.
Test: llvm-objdump -d
Test: bionic-unit-tests-static --gtest_filter='math*'
Bug: https://github.com/google/android-riscv64/issues/11
Change-Id: I4230005abcd8d6025d82f1e8afe5831fad2db04d
The next NDK to take these headers only supports API 21 and later, so
clean up some of the trivial cruft.
Test: treehugger
Change-Id: Ib735a776d244cc82858f2ed629dd63a54dbaf650
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
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
The clang builtins for arm32 give us identical code to what we had for
sqrt()/sqrtf(), and significantly better (neon) code for
floor()/floorf() than the integer-only implementations we had.
Test: llvm-objdump
Change-Id: I224bcfcf4739a80e1a7cdd07b0b1fa232fdf2dab
Once we have an llvm with https://reviews.llvm.org/D136508, we will be
able to defer to more compiler builtins, but for now let's do what we
can...
Test: llvm-objdump (plus the tests still pass!)
Change-Id: Ia5c704409ca88ab1a02342c1b5dde8525da95243
We don't support GCC any more, and clang's got better since this commit
was written. It doesn't produce _identical_ code, but it's a similar
single-instruction bit twiddle.
This also doesn't regress x86 for fabsl (that code looks the same before
and after) and there is no riscv32.
Test: llvm-objdump -d
Change-Id: I7acea6fd26f8760763f3744201ed42a99186562b
We stopped accepting new code in this form (compiler output from
compilers we don't have compiling source we don't have [or possibly the
same source we do have --- how would be know?]) years ago, but never
went back to clean up existing instances.
This doesn't affect the string/memory routines, which are intelligible,
nor all of the libm stuff (we're keeping the intelligible subset), but
does affect all the trig functions.
The right way to do this is to either have commented hand-written
assembler (which we have always taken, and will continue to take) or to
have C/C++ source that can be built with LLVM (which will then be built
as part of the regular build). This is what we do for arm/arm64, for
example, with the C/C++ source coming from
https://github.com/ARM-software/optimized-routines and being mirrored
in external/arm-optimized-routines, and built by Android's clang at
build time.
Test: treehugger
Change-Id: Icd69ef34b8a9ea16ea2b7d5d6587c2a9143b7740
This is mainly just to match what we have for arm64.
The test failures before and after this change are all for the long
double variant, which this change doesn't touch. (The problem there is
that clang is calling `__fixtfdi` for the cast in lrintl(), but that
doesn't respect the current rounding mode, which lrintl() is required
to do. `#pragma STDC FENV_ACCESS ON` doesn't fix this, so there's going
to be some llvm work needed to fix this.)
I've replaced the ASSERTs with EXPECTs in the relevant test to ensure
we're checking all the other assertions despite the `long double`
failures.
Test: bionic-unit-tests-static
Change-Id: Ia24bf21619631b6f8b3b607d30536011bb4cd826
The FE_* rounding mode constants have different values on different
architectures, so you can't just copy & paste the validity check from
one to another, like I did here...
Bug: http://b/254501880
Test: treehugger
Change-Id: I2ffa766ffcbe22c1afcd28eab4bd964100dc2d98
The macOS man page was helpful in advancing my understanding of
feupdateenv() in particular.
Test: treehugger
Change-Id: I511e8b31ac16f3fdf08b42eee5a2e6558ec3b70b
The clang prebuilts now provide a single module with per-architecture
variants instead of a module per architecture.
Bug: 220019988
Test: m checkbuild
Ignore-AOSP-First: topic contains vendor projects
Change-Id: I079f36f94b13e06d59a16cf665b65db76084021a
Merged-In: I079f36f94b13e06d59a16cf665b65db76084021a
There's potential here to maybe lose some/all of builtins.cpp, but I'll
look at that separately later.
Test: treehugger
Change-Id: I2c2bc1d0753affdd214daeb09fa1ac7cd73db347
clang was getting in the way of a strftime(3) optimization, and smaller
hammers weren't working, and this seems like the right choice for libc
anyway? If we have code that can usefully be optimized, we should do it
in the source. In general, though, no libc/libm author should be
ignorant of memset(3) or memcpy(3), and would have used it themselves if
it made sense. (And the compiler isn't using profiling data or anything;
it's just always assuming it should use the functions, and doesn't
consider whether the cost of the calls can be amortized or not.)
Test: treehugger
Change-Id: Ia7e22623e47bfbfcfe46c1af0d95ef7e8669c0f6
* -Wstatic-in-inline found in
libm/upstream-freebsd/lib/msun/src/s_lround.c
Test: mm in bionic/tests
Bug: 201432564
Bug: 202752322
Change-Id: I4d506fa539ab0de939d85924a5fd9a61644e4fb0
Bug: http://b/157914307
This pragma enables
- -frounding-math, i.e. rounding mode set at runtime are honored
- -ffp-exception-behavior=strict, i.e. FPE semantics are preserved.
- Prevents use of FMA instructions.
Test: Build toolchain without revert https://r.android.com/1298100
and run bionic-unit-tests.math_h*
Change-Id: I6249b20c93e0fd4ebbdfbe433da4ad4a65d3747b
Use target.bionic.system_shared_libs when it is used to limit the
default shared libraries (as opposed to remove them completely).
This avoids attempting to add a host dependency on libc when
system_shared_libs is modified to apply to all variants.
Bug: 193559105
Test: m checkbuild
Change-Id: I8d623321ce5145cf2968f83f78b5cb50711290f4
Remove the vestigial llndk_library and replace it with properties
in the llndk clause of the implementation cc_library.
In order to reduce duplication of the arch-specific headers used
by the implementation and LLNDK, rename libc_headers_arch to
libc_llndk_headers and hoist the "include" directory out of it,
since that directory is preproccessed separately for LLNDK
libraries.
Bug: 170784825
Test: m checkbuild
Test: compare out/soong/build.ninja
Change-Id: I75f0ff9129d910640da55eee6a6387467e6e4a9d
Auto-generate NOTICE files for all the directories, and for each one
individually rather than mixing libc and libm together.
Test: N/A
Change-Id: I7e251194a8805c4ca78fcc5675c3321bcd5abf0a
* https://reviews.llvm.org/D90316 changed warning on
FENV_ACCESS pragma from unknown to ignored.
Existing -Wno-unknown-pragmas cannot suppress the new
-Wignored-pragmas.
Bug: 178516148
Test: make with WITH_TIDY=1
Change-Id: I783feef35324ef43946efca844cd944410875bfa
For backwards compatibility (e.g. with old apps), arm32 libc.so and
libm.so export some of the builtins. On 32-bit x86, libc.so also
exports some of the builtins.
The non-exported variant of the builtins will eventually have hidden
symbols but doesn't currently because D93431 hasn't been merged into
our toolchain yet. See:
- https://reviews.llvm.org/D93431
- I44ec79728db92c089e2f39823c35b6f97d24c1ab in toolchain/llvm_android
Bug: http://b/153025717
Test: bionic unit tests
Change-Id: Ic489cb06a07ef61412502fc65a21b0cf630c11ed
