[BUG] ARMv7 undefined reference to '__aeabi_d2h' with -Oz flag

[h6197627]

Description

I am getting

undefined reference to '__aeabi_d2h'

while trying to compile this code for ARMv7 architecture with -Oz optimization flag (which is set by default if cmake toolchain file is used):

int main()
{
    const int cnt = 4;
    double double_array[cnt];
    __fp16 half_array[cnt];
    for (int i = 0; i < cnt; ++i)
        double_array[i] = i;
    for(int i = 0; i < cnt; ++i)
        half_array[i] = (__fp16)double_array[i];

    return (int)half_array[2]; // Just to cheat optimizer
}

Compilation command is:

${NDK}/toolchains/llvm/prebuilt/linux-x86_64/bin/armv7a-linux-androideabi21-clang++ -march=armv7-a -Oz test.cpp -o v7

At the same time, compiling with -O2 is successful. Also ARMv8 can be compiled with both -Oz and -O2. Using this Makefile only v7_z target is failing

v7_2:
	${NDK}/toolchains/llvm/prebuilt/linux-x86_64/bin/armv7a-linux-androideabi21-clang++ -march=armv7-a -O2 test.cpp -o v7_2
v7_z:
	${NDK}/toolchains/llvm/prebuilt/linux-x86_64/bin/armv7a-linux-androideabi21-clang++ -march=armv7-a -Oz test.cpp -o v7_z
v8_2:
	${NDK}/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android21-clang++ -march=armv8-a -O2 test.cpp -o v8_2
v8_z:
	${NDK}/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android21-clang++ -march=armv8-a -Oz test.cpp -o v8_z

Environment Details

Not all of these will be relevant to every bug, but please provide as much
information as you can.

• NDK Version: 21.0.6113669
• Build system: manually written Makefile
• Host OS: Ubuntu 18.04
• ABI: armeabi-v7a
• NDK API level: 21

[DanAlbert]

@h6197627 do you know if this was a regression from r20?

[stephenhines]

I think this is a consequence of not shipping compiler-rt as the default rtlib for Android. This function isn't provided by libgcc at all, and thus you need to link against Clang's libclang-rt.builtins-*.a for your target architecture in order to provide this function.

[DanAlbert]

I figured, jw about triage. We do link libcompiler_rt-extras along with libgcc. Might be that we need to alter that to use libclang-rt.builtins.

[h6197627]

@h6197627 do you know if this was a regression from r20?

No, r20b has the same error.

OK, changing make file to

v7_z:
	${NDK}/toolchains/llvm/prebuilt/linux-x86_64/bin/armv7a-linux-androideabi21-clang++ -march=armv7-a -Oz test.cpp -o v7_z -L${NDK}/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/9.0.8/lib/linux -lclang_rt.builtins-arm-android

solves compilation error.

So, should I close this issue assuming that users should explicitly provide this library to linker or is it something that you can automate (for me as an ordinary NDK user, of course, second choice is preferable)?

For reference: original issue where error first occurred opencv/opencv#16596 (also fixes by providing -L${NDK}/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/9.0.8/lib/linux -lclang_rt.builtins-arm-android)

[DanAlbert]

Thanks for confirming. We'll leave it open since that should be fixed on our end.

[stephenhines]

Many/most users won't need this workaround, since they won't be using half precision. For that reason, I don't think we should necessarily modify the NDK build rules. Having a documented workaround is probably the important part.

@DanAlbert do you want to open a feature request for switching to libclang_rt.builtins and then just dupe this there? I'm not sure how you want to use this bug tracker for features, or if you would prefer that we just track the switch to libclang_rt.builtins for the NDK internally?

[DanAlbert]

Switching is blocked on having a functioning unwinder. Once we're fully onto LLVM's unwinder, then we can switch.

Filed #1231 to track libclang_rt (I could have sworn we already had one open, but I think maybe it was repurposed and closed when we picked up libcompiler_rt-extras?), but it's blocked by #1230.

I remembered we can't actually fix this the way I'd hoped (by having the libgcc linker script automatically link libclang_rt) because the libclang_rt libraries aren't on the default search path. The status quo works for almost all cases, so I think you're right: the bug title here will be extremely googleable for anyone that is using half float and the work around is trivial, so that's fine for another few releases.

[DoDoENT]

I'm having the same issue when compiling OpenCV 4.5.1 regardless if I use -Oz, -Os or -O2. Linking with clang_rt.builtins-arm-android does help, but it's a dirty hack.

I am using NDK r22.

[DanAlbert]

I'm having the same issue when compiling OpenCV 4.5.1 regardless if I use -Oz, -Os or -O2. Linking with clang_rt.builtins-arm-android does help, but it's a dirty hack.

I am using NDK r22.

I believe it's finally possible for us to use the buildins by default in r23, so that's good news.

The other bugs in my previous comment are the ones you'll want to subscribe to. There are no small fixes we can make so this one won't be getting updates.