Skip to content
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

Closed
DanAlbert opened this issue Feb 2, 2017 · 16 comments
Closed

No __unorddf2 in NDK for aarch64 #294

DanAlbert opened this issue Feb 2, 2017 · 16 comments
Assignees
Labels
for-beta1 Bugs that should be fixed in time for beta 1.
Milestone

Comments

@DanAlbert
Copy link
Member

__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

@DanAlbert
Copy link
Member Author

DanAlbert commented Feb 2, 2017

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).

@DanAlbert
Copy link
Member Author

Upstream bug about this: https://llvm.org/bugs/show_bug.cgi?id=16404

@DanAlbert
Copy link
Member Author

Good news is that the newer Clang (the one I'm verifying for r15 right now) doesn't emit __unorddf2 for the libc++ tests. There was some talk upstream of trying to avoid using things not available in libgcc, so maybe that happened? Or maybe those calls are just being inlined now. @stephenhines @pirama-arumuga-nainar, any idea?

@stephenhines
Copy link
Collaborator

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.

@pirama-arumuga-nainar
Copy link
Collaborator

We added unorddf2 to compiler_rt-extras (https://android-review.googlesource.com/#/c/243673/). Is that not included with the NDK?

@DanAlbert
Copy link
Member Author

They are probably just generating different code.

Okay, I figured as much.

We added unorddf2 to compiler_rt-extras (https://android-review.googlesource.com/#/c/243673/). Is that not included with the NDK?

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).

@DanAlbert
Copy link
Member Author

Moving to compiler-rt is somewhat non-trivial because it's difficult to get building for ICS. Moving to r17.

@fornwall
Copy link

@DanAlbert Is the plan still to move from libgcc to compiler-rt for r17?

@DanAlbert DanAlbert self-assigned this Nov 16, 2017
@DanAlbert
Copy link
Member Author

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.

@DanAlbert
Copy link
Member Author

(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)

hubot pushed a commit to aosp-mirror/platform_development that referenced this issue Feb 2, 2018
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
hubot pushed a commit to aosp-mirror/platform_development that referenced this issue Feb 14, 2018
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)
miodragdinic pushed a commit to MIPS/external-compiler-rt that referenced this issue Mar 14, 2018
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
@DanAlbert DanAlbert modified the milestones: r17, r18 Mar 29, 2018
@DanAlbert
Copy link
Member Author

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.

miodragdinic pushed a commit to MIPS/external-libcxx that referenced this issue Apr 17, 2018
Test: ndk/checkbuild.py && ndk/run_tests.py
Bug: android/ndk#294
Change-Id: I0b73880efb981e5d75c813b01b2bdaa22bcdabe9
(cherry picked from commit faa65d70c87cc59a3e7f540bd44df57413a5308c)
miodragdinic pushed a commit to MIPS/ndk that referenced this issue Apr 17, 2018
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
miodragdinic pushed a commit to MIPS/ndk that referenced this issue Apr 17, 2018
Test: ./run_tests.py --suite libc++ --abi x86_64
Bug: android/ndk#294
Change-Id: I4756693e0cf0459b9488d940358035ac91214134
miodragdinic pushed a commit to MIPS/prebuilts-ndk that referenced this issue Apr 17, 2018
Test: ndk/checkbuild.py && ndk/validate.py
Bug: android/ndk#272
Bug: android/ndk#294
Change-Id: Iea240e8b2241576121db1acf3a1bd9cfe3426677
@DanAlbert
Copy link
Member Author

NDK r17 includes libcompiler_rt-extas.a which includes the missing libcalls. Should be able to work around issues with -lcompiler_rt-extas until we manage to get fully switched to compiler-rt.

@rprichard rprichard modified the milestones: r18, r19 Jun 21, 2018
@DanAlbert DanAlbert added the for-beta1 Bugs that should be fixed in time for beta 1. label Oct 17, 2018
@DanAlbert
Copy link
Member Author

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.

@DanAlbert
Copy link
Member Author

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.

@DanAlbert
Copy link
Member Author

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.

@DanAlbert
Copy link
Member Author

In r19.

charleseb pushed a commit to MotorolaMobilityLLC/external-compiler-rt that referenced this issue Dec 5, 2018
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
grendello added a commit to grendello/xamarin-android that referenced this issue Aug 26, 2019
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.
grendello added a commit to grendello/xamarin-android that referenced this issue Aug 26, 2019
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.
grendello added a commit to grendello/xamarin-android that referenced this issue Aug 26, 2019
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.
grendello added a commit to grendello/xamarin-android that referenced this issue Aug 26, 2019
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.
jonpryor pushed a commit to dotnet/android that referenced this issue Aug 27, 2019
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.
chenyt9 pushed a commit to MotorolaMobilityLLC/external-compiler-rt that referenced this issue Nov 21, 2019
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
mbissaromoto pushed a commit to MotorolaMobilityLLC/external-compiler-rt that referenced this issue Sep 6, 2021
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
for-beta1 Bugs that should be fixed in time for beta 1.
Projects
None yet
Development

No branches or pull requests

5 participants