-
Notifications
You must be signed in to change notification settings - Fork 257
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No __unorddf2 in NDK for aarch64 #294
Comments
Anyone else landing here: only real workaround would be to add a definition of these things to your code. The compiler-rt versions are dual MIT/University of Illinois Open Source licensed: https://android.googlesource.com/platform/external/compiler-rt/+/master/lib/builtins/muloti4.c The only things that should be missing are some of the less commonly needed builtins (128-bit math). |
Upstream bug about this: https://llvm.org/bugs/show_bug.cgi?id=16404 |
Good news is that the newer Clang (the one I'm verifying for r15 right now) doesn't emit |
They are probably just generating different code. I didn't spot anything that makes me believe that "inlining" is happening, since the calls would still be to a nonexistent compiler-rt set of builtins. This is a tricky problem that will likely keep recurring until we can properly switch over to using compiler-rt for builtins. |
We added unorddf2 to compiler_rt-extras (https://android-review.googlesource.com/#/c/243673/). Is that not included with the NDK? |
Okay, I figured as much.
No, it isn't. We don't have control of our users' build systems, so something like compiler_rt-extras doesn't really work for us (we can try doing something with a linker script, but haven't yet). |
Moving to compiler-rt is somewhat non-trivial because it's difficult to get building for ICS. Moving to r17. |
@DanAlbert Is the plan still to move from libgcc to compiler-rt for r17? |
I think if we don't manage to fully migrate in this release, we're going to have to at least perform some tricks like we do in the platform to provide the missing symbols. |
(the trick we do is link a libcompiler-rt-extras into everything alongside libgcc; it only contains a handful of symbols that libgcc doesn't provide) |
Still not ready to adopt the new static libraries, but we've needed this for a while now. Copy it into place for now. These came from the current prebuilts/ndk, which themselves came from AOSP master build 4567395. Test: ndk/checkbuild.py && ndk/run_tests.py Bug: android/ndk#294 Change-Id: Ia713a957df5c913b36d5f6c8fff35bbb11315ae8
Still not ready to adopt the new static libraries, but we've needed this for a while now. Copy it into place for now. These came from the current prebuilts/ndk, which themselves came from AOSP master build 4567395. Test: ndk/checkbuild.py && ndk/run_tests.py Bug: android/ndk#294 Change-Id: Ia713a957df5c913b36d5f6c8fff35bbb11315ae8 (cherry picked from commit bbdeccf)
The NDK can't fully switch to compiler-rt until the unwinders have been sorted out, so it needs this for the time being. Test: build/soong/scripts/build-ndk-prebuilts.sh Bug: android/ndk#294 Change-Id: I65516f4369f4e6c39b54e3c049df224b8d908d31
Not far along enough with testing for this for me to be happy with it for r17. As I said above though, the main case where this was causing issues is no longer occurring. |
Test: ndk/checkbuild.py && ndk/run_tests.py Bug: android/ndk#294 Change-Id: I0b73880efb981e5d75c813b01b2bdaa22bcdabe9 (cherry picked from commit faa65d70c87cc59a3e7f540bd44df57413a5308c)
Clang generates calls to this, but we don't actually have support for it. Test: ./run_tests.py --suite libc++ --abi arm64-v8a --skip-run Bug: android/ndk#294 Change-Id: Idf9ee0638c65e6df83b66e1121bf76b1c6ace001
Test: ./run_tests.py --suite libc++ --abi x86_64 Bug: android/ndk#294 Change-Id: I4756693e0cf0459b9488d940358035ac91214134
Test: ndk/checkbuild.py && ndk/validate.py Bug: android/ndk#272 Bug: android/ndk#294 Change-Id: Iea240e8b2241576121db1acf3a1bd9cfe3426677
NDK r17 includes libcompiler_rt-extas.a which includes the missing libcalls. Should be able to work around issues with |
I don't remember the current status here. We definitely have libcompiler_rt-extas in the NDK, but I think it's not used. Will check in on this before r19 beta 1, but if there's much work that needs to be done for it then it may land as part of beta 2. |
Looks like it's still in the same state as r17: libcompiler_rt-extras is present but not used. https://android-review.googlesource.com/c/platform/ndk/+/793579 adds libcompiler_rt-extras to the libgcc linker script to make this transparent from the user's perspective. |
Submitted to master. Leaving this open because I'm not sure when the r19 branch point is and I want to make sure it gets into that branch. |
In r19. |
The NDK can't fully switch to compiler-rt until the unwinders have been sorted out, so it needs this for the time being. Test: build/soong/scripts/build-ndk-prebuilts.sh Bug: android/ndk#294 Change-Id: I65516f4369f4e6c39b54e3c049df224b8d908d31
Context: android/ndk#294 Context: android/ndk#295 Context: https://bugs.llvm.org/show_bug.cgi?id=16404 Add a couple of functions to `Utils` taking advantage of the compiler builtin functions to perform integer addition and multiplication while checking for overflows. If an overflow is detected, the application is terminated. Due to a bug in Android NDK's clang, the multiplication is not performed using "open" types but rather, currently, only `size_t` for the multiplication operands. Using a template for them would result in a link error as the compiler would generate code to use 128-bit integers to perform the operation, attempting to call the `__muloti4` intrinsic function which is usually defined in `libgcc`, `libcompiler_rt` or `libcompiler_rt-extras` libraries. In the NDK case the 64-bit targets do not contain implementation of the function in neither of the libraries mentioned above.
Context: android/ndk#294 Context: android/ndk#295 Context: https://bugs.llvm.org/show_bug.cgi?id=16404 Add a couple of functions to `Utils` taking advantage of the compiler builtin functions to perform integer addition and multiplication while checking for overflows. If an overflow is detected, the application is terminated. Due to a bug in Android NDK's clang, the multiplication is not performed using "open" types but rather, currently, only `size_t` for the multiplication operands. Using a template for them would result in a link error as the compiler would generate code to use 128-bit integers to perform the operation, attempting to call the `__muloti4` intrinsic function which is usually defined in `libgcc`, `libcompiler_rt` or `libcompiler_rt-extras` libraries. In the NDK case the 64-bit targets do not contain implementation of the function in neither of the libraries mentioned above.
Context: android/ndk#294 Context: android/ndk#295 Context: https://bugs.llvm.org/show_bug.cgi?id=16404 Add a couple of functions to `Utils` taking advantage of the compiler builtin functions to perform integer addition and multiplication while checking for overflows. If an overflow is detected, the application is terminated. Due to a bug in Android NDK's clang, the multiplication is not performed using "open" types but rather, currently, only `size_t` for the multiplication operands. Using a template for them would result in a link error as the compiler would generate code to use 128-bit integers to perform the operation, attempting to call the `__muloti4` intrinsic function which is usually defined in `libgcc`, `libcompiler_rt` or `libcompiler_rt-extras` libraries. In the NDK case the 64-bit targets do not contain implementation of the function in neither of the libraries mentioned above.
Context: android/ndk#294 Context: android/ndk#295 Context: https://bugs.llvm.org/show_bug.cgi?id=16404 Add a couple of functions to `Utils` taking advantage of the compiler builtin functions to perform integer addition and multiplication while checking for overflows. If an overflow is detected, the application is terminated. Due to a bug in Android NDK's clang, the multiplication is not performed using "open" types but rather, currently, only `size_t` for the multiplication operands. Using a template for them would result in a link error as the compiler would generate code to use 128-bit integers to perform the operation, attempting to call the `__muloti4` intrinsic function which is usually defined in `libgcc`, `libcompiler_rt` or `libcompiler_rt-extras` libraries. In the NDK case the 64-bit targets do not contain implementation of the function in neither of the libraries mentioned above.
Context: android/ndk#294 Context: android/ndk#295 Context: https://bugs.llvm.org/show_bug.cgi?id=16404 Add a couple of functions to `Utils` taking advantage of the compiler builtin functions to perform integer addition and multiplication while checking for overflows. If an overflow is detected, the application is terminated. Due to a bug in Android NDK's clang, the multiplication is not performed using "open" types but rather, currently, only `size_t` for the multiplication operands. Using a template for them would result in a link error as the compiler would generate code to use 128-bit integers to perform the operation, attempting to call the `__muloti4` intrinsic function which is usually defined in `libgcc`, `libcompiler_rt` or the `libcompiler_rt-extras` libraries. In the NDK case the 64-bit targets do not contain implementation of the function in any of the libraries mentioned above.
The NDK can't fully switch to compiler-rt until the unwinders have been sorted out, so it needs this for the time being. Test: build/soong/scripts/build-ndk-prebuilts.sh Bug: android/ndk#294 Change-Id: I65516f4369f4e6c39b54e3c049df224b8d908d31
The NDK can't fully switch to compiler-rt until the unwinders have been sorted out, so it needs this for the time being. Test: build/soong/scripts/build-ndk-prebuilts.sh Bug: android/ndk#294 Change-Id: I65516f4369f4e6c39b54e3c049df224b8d908d31
__unorddf2 isn't in libgcc for aarch64, but clang emits calls for it when compiling some libc++ tests. One possible solution for this would be to switch to compiler-rt instead of libgcc, but that's not something that will happen for r15.
One such test: sources/cxx-stl/llvm-libc++/test/std/numerics/complex.number/complex.transcendentals/atan.pass.cpp
The text was updated successfully, but these errors were encountered: