Unoptimised builds of compiler_builtins on ARM have references to core::panicking::panic

[TimNN]

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

[TimNN]

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

As far as I can tell, compiler_builtins is already compiled without debug-assertions.

[est31]

I was with the impression that all builds of compiler_builtins were optimized? In this case it seems we have some dead code remnant of a panic call. I think its too hard to avoid all of them, and considering that we want to increase the amount of rust code code in the compiler_builtins implementation (see https://github.com/rust-lang-nursery/compiler-builtins), it will only get worse. So what about always enabling optimisations, at least for the std crates?

[alexcrichton]

AFAIK we can't disable debug assertions on a per-function basis, so we'd need to add an intrinsic perhaps here.

[TimNN]

I'll try the "fix with intrinsics" approach and see if that fixes the problem.

[est31]

I'm not sure IF this kind of panic freedom should be a goal (after all, who wants unoptimized builds?), but if it is a goal, this change should be backported to the upcoming replacement of this crate, the pure rust compiler builtins: https://github.com/rust-lang-nursery/compiler-builtins

[est31]

(with "this change" I mean #40521)