[BUG] armv7a + simd ld.lld segmentation fault during linking NEON code

[arturbac]

Description

With ndk r-21.* clang ld.lld started to fail generating neon instructions when source code uses neon intrinsics for armeabi-v7a. With ndk r-20 there is no problem and no segmentation fault during linking stage.
ndk-r21 still generates proper code for armv-8a

1.  Running pass 'Function Pass Manager' on module 'ld-temp.o'.
   

2.  Running pass 'ARM Instruction Selection' on function '@_ZN4conv27yCrCb2rgb_aarch64_yps1_chs1E18yuv_data_info_tmplIPKSt4byteEPhj'
   

#0 0x0000000000e59f92 (/opt/android-sdk/ndk/21.1.6352462/toolchains/llvm/prebuilt/linux-x86_64/bin/ld.lld+0xe59f92)
#1 0x0000000000e5a727 (/opt/android-sdk/ndk/21.1.6352462/toolchains/llvm/prebuilt/linux-x86_64/bin/ld.lld+0xe5a727)
#2 0x00007f0ddea1b0b0 __restore_rt (/lib64/libpthread.so.0+0x130b0)
#3 0x000000000143b92d (/opt/android-sdk/ndk/21.1.6352462/toolchains/llvm/prebuilt/linux-x86_64/bin/ld.lld+0x143b92d)
#4 0x00007ffc234315f0
clang++: error: unable to execute command: Segmentation fault (core dumped)
clang++: error: linker command failed due to signal (use -v to see invocation)
ninja: build stopped: subcommand failed.

Environment Details

• NDK Version: 21.* (0 and 1)
• Host OS: Linux, gentoo
• ABI: armeabi-v7a
• NDK API level: 21

I attached linking output with seg fault and preprocessed source code of function mentioned in linker fault. I cannot narrow down more what causes seg fault than preprocessed source file.
linking_fault.txt

yuv_to_rgb_alligned.cc.txt

[DanAlbert]

I think clang usually generates a tarball of the repro case for a crash. Does LLD not do that? If you have that, that'll help. Otherwise, it looks like we have the preprocessed source and the build commands, so hopefully that's enough (thanks for providing those!)

[DanAlbert]

r21c is already being finalized, so this will be in r21d at the earliest.

[arturbac]

I think clang usually generates a tarball of the repro case for a crash.

Not in case of linker failure (ld.lld segfault), ld.lld fails at the end of entire build when starts generating assembly from precompiled byte code. The only clue is hopefully source function name.
I had to generate preprocessed output of source explicitly by myself taking into account this function name.

[arturbac]

BTW: If You need any other output just let me know and supply clang/ld.lld command to execute.

[stephenhines]

The input file here isn't enough to reproduce the issue unfortunately. If you pass -v to the failing command line, you can get it to dump the exact subcommands that are being run. Then, the ld.lldcommand in there can be run with the --reproduce=repro.tar option to create a repro.tar file that will include all the necessary inputs. You can verify that it reproduces for you by untarring that file and then running ld.lld @response.txt inside of that directory.

[arturbac]

Cant attach it here, after compressing with xz it take 62MB and here is 10MB file limit
So I put it into my web server, let me know when I can delete it.
http://ebasoft.com.pl/repro.tar.xz

[stephenhines]

Wow, ok. I just pulled it down locally here. I can attach it internally to a bug as needed, so that others can look if necessary. You can remove your copy from your server. Thanks.

[arturbac]

I would be glad if You dont put my entire code here, there are all my archives after compilation.

[stephenhines]

I'm not going to upload it to the public tracker (or even internally if I can avoid it).

NDK r21b reproduces it exactly:

srhines@ringworld:__:repro$ /disk//android_trees/aosp/prebuilts/clang/host/linux-x86/clang-r365631c1/bin/ld.lld @response.txt
Stack dump:
0.      Program arguments: /disk//android_trees/aosp/prebuilts/clang/host/linux-x86/clang-r365631c1/bin/ld.lld @response.txt 
1.      Running pass 'Function Pass Manager' on module 'ld-temp.o'.
2.      Running pass 'ARM Instruction Selection' on function '@_ZN4conv27yCrCb2rgb_aarch64_yps1_chs1E18yuv_data_info_tmplIPKSt4byteEPhj'
#0 0x0000000000e59f92 (/disk//android_trees/aosp/prebuilts/clang/host/linux-x86/clang-r365631c1/bin/ld.lld+0xe59f92)
#1 0x0000000000e5a727 (/disk//android_trees/aosp/prebuilts/clang/host/linux-x86/clang-r365631c1/bin/ld.lld+0xe5a727)
#2 0x00007f2a6a344520 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x13520)
#3 0x000000000143b92d (/disk//android_trees/aosp/prebuilts/clang/host/linux-x86/clang-r365631c1/bin/ld.lld+0x143b92d)
#4 0x00007fffce92e6f0 
Segmentation fault

Using our latest toolchain, I see that the bug is still there. We'll track it down.

srhines@ringworld:__:repro$ /disk//android_trees/aosp/prebuilts/clang/host/linux-x86/clang-r383902/bin/ld.lld @response.txt
'+vfp2d16' is not a recognized feature for this target (ignoring feature)
'+vfp2d16sp' is not a recognized feature for this target (ignoring feature)
'+vfp2d16' is not a recognized feature for this target (ignoring feature)
'+vfp2d16sp' is not a recognized feature for this target (ignoring feature)
Stack dump:
0.      Program arguments: /disk//android_trees/aosp/prebuilts/clang/host/linux-x86/clang-r383902/bin/ld.lld @response.txt 
1.      Running pass 'Function Pass Manager' on module 'ld-temp.o'.
2.      Running pass 'ARM Instruction Selection' on function '@_ZN4conv27yCrCb2rgb_aarch64_yps1_chs1E18yuv_data_info_tmplIPKSt4byteEPhj'
#0 0x000000000187ed95 (/disk//android_trees/aosp/prebuilts/clang/host/linux-x86/clang-r383902/bin/ld.lld+0x187ed95)
#1 0x000000000187f4c0 (/disk//android_trees/aosp/prebuilts/clang/host/linux-x86/clang-r383902/bin/ld.lld+0x187f4c0)
#2 0x000000000187f42d (/disk//android_trees/aosp/prebuilts/clang/host/linux-x86/clang-r383902/bin/ld.lld+0x187f42d)
#3 0x00007f93a2271520 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x13520)
#4 0x00000000015b4ea6 (/disk//android_trees/aosp/prebuilts/clang/host/linux-x86/clang-r383902/bin/ld.lld+0x15b4ea6)
Trace/breakpoint trap

[stephenhines]

With a build from TOT LLVM, I see that we are hitting an assertion in the ARM backend. I can try to reduce this down and fix it.

unexpected intrinsic for Neon base update
UNREACHABLE executed at /disk/llvm/llvm-project/llvm/lib/Target/ARM/ARMISelLowering.cpp:13412!

[stephenhines]

Running just llc on the following reduced file triggers the bug. I'll talk to ARM today about it.

broken.ll.txt

[arturbac]

Have You checked ndk r20 ?
ld.lld works ok, and of course code works ok on armv7a+neon and armv8a.
And i don't get where is problem with vld1x2 or vst3 ?
https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics?page=1&search=vld1
uint8x8_t vld1_u8 (uint8_t const * ptr)
uint8x8x2_t vld1_u8_x2 (uint8_t const * ptr)
Supported architectures v7/A32/A64

[stephenhines]

https://bugs.llvm.org/show_bug.cgi?id=45824 is the upstream LLVM bug I filed for this. I changed to using the original reduced input file, since Pirama pointed out that I might be causing different problems when stripping away various attributes.

bugpoint-reduced-simplified.ll.txt

[arturbac]

Hope You will have more luck, maybe bug will be more importand, I've reported 5 bugs there all still have status NEW, 4 of them were reported 7 years ago

https://bugs.llvm.org/buglist.cgi?email2=artur%40ebasoft.com.pl&emailreporter2=1&emailtype2=substring&list_id=186405&order=Importance&query_format=advanced&resolution=---

[kimishpatel]

I have just run into this issue today as well. My ndk is r21 as well. Have not tried on 20 though. But I did try with -O0 in which case things work fine.

[kimishpatel]

For my case I see that it is not necessarily due to any specific intrinsic. I think this is strongly tied to optimization pass as mentioned in the bug, since when I remove certain code path I was able to compile it. It was not important what I removed though. So I suspect it just triggers some optimization path that results in seg fault.

[rprichard]

For r22, this bug was fixed in the r399163b clang, in https://android-review.googlesource.com/c/toolchain/llvm_android/+/1440863.

(The NDK bugs #1248 and #1303 might be duplicates: see https://bugs.llvm.org/show_bug.cgi?id=46615#c5.)