Performing an ARM build with --disable-optimize causes libcompiler_builtins.rlib (for ARM) to have references to core::panicking::panic. Note that the IR does not contain calls to those functions, however readelf / nm shows references to them.

As far as I can tell, this then causes libstd.so to have core::panicking::panic as a non-public symbol, leading to build failures later on.

This does not affect x86_64 linux as far as I can tell.

The IR and readelf output of compiler_builtins (these were generated with LLVM 4.0, but the problem also occurs with LLVM 3.9).

Edit: with LLVM 4.0, the following symbols have references to core::panic::panicking:

_ZN4core3num21_$LT$impl$u20$i64$GT$15overflowing_shr17hbb25084440bea1ffE
_ZN4core3num21_$LT$impl$u20$u32$GT$15overflowing_shl17hebf019cda7aaad4eE
_ZN4core3num21_$LT$impl$u20$u32$GT$15overflowing_shr17h28c64480ffb5b769E
_ZN4core3num21_$LT$impl$u20$u64$GT$15overflowing_shl17h057b937dda71a8daE
_ZN4core3num21_$LT$impl$u20$u64$GT$15overflowing_shr17h77d38bf1169ec68aE
_ZN4core3num22_$LT$impl$u20$i128$GT$15overflowing_shl17h264aab4280fbd05fE
_ZN4core3num22_$LT$impl$u20$i128$GT$15overflowing_shr17ha7a3617a02c8f37bE
_ZN4core3num22_$LT$impl$u20$u128$GT$15overflowing_shl17h7cbe64bca4ffa03cE
_ZN4core3num22_$LT$impl$u20$u128$GT$15overflowing_shr17h363dc51c526c1d4fE
__ashlti3
__ashrti3
__lshrti3
__multi3
__fixunsdfti
__fixunssfti
__fixdfti
__fixsfti

Regarding a fix, see @nagisa's comment #40123 (comment):

The panicking is introduced by overflowing_sh* which has implementation that looks like this:

(self >> (rhs & ($BITS - 1)), (rhs > ($BITS - 1)))

That shift over there is a checked shift and does not get optimised in no-opt mode. wrapping_sh* are implemented in terms of this overflowing_sh*. These could be fixed with some intrinsics, maybe?

Alternatively, is there maybe a way to disable debug-assertions on a per-function basis?

cc @nagisa, @alexcrichton, #40123