rustc SIGILL since qsort_r patches

[Andrew Pinski]

On Sat, Nov 4, 2023 at 5:55 PM Cristian Rodríguez <cristian@rodriguez.im> wrote:
>
> Hi:
>
> After quite some head scratching I found the recent qsort_r patches triggers a bug "somewhere" that makes rustc LTO end in sigkill (ud2)
>
> happens compiling anything in release mode with any toolchain (stable, beta, nightly)
>
> #0  0x000015129e40516a in int llvm::array_pod_sort_comparator<llvm::BranchFolder::MergePotentialsElt>(void const*, void const*) () from /home/crrodriguez/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-17-rust-1.75.0-nightly.so
>
> #1  0x00001512a0043779 in __GI___qsort_r (pbase=0x15128c90bd80, total_elems=<optimized out>, size=0x10, cmp=<optimized out>, arg=<optimized out>) at qsort.c:335
>
> #2  0x000015129e4df6e6 in llvm::BranchFolder::TryTailMergeBlocks(llvm::MachineBasicBlock*, llvm::MachineBasicBlock*, unsigned int) () from /home/crrodriguez/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-17-rust-1.75.0-nightly.so
>

I think this is a bug in LLVM's
BranchFolder::MergePotentialsElt::operator< code:
See: https://llvm.org/doxygen/BranchFolding_8cpp_source.html

Specifically it has the following comment:
// _GLIBCXX_DEBUG checks strict weak ordering, which involves comparing
489 // an object with itself.
490#ifndef _GLIBCXX_DEBUG
491 llvm_unreachable("Predecessor appears twice");
492#else
493 return false;
494#endif

Well glibc's qsort implementation will also now compare with itself.

Thanks,
Andrew

> git head == bad
> 2.38   == good
>
> Main interest is to know if I am not alone and if anyone else has observed this problem so far.
> Thanks..