add a regression test that tests for the presence of "compiler-rt" intrinsics

[japaric]

We need this to make sure we don't accidentally lose any intrinsic during the process of porting
them to Rust (#35437).

One possible way to do this is to just compile a program, like the one below, that depends on
several intrinsics:

// NOTE omitted lang_items for brevity
#![feature(start)]
#![no_std]

// This crates provides the intrinsics. We want to test that it provides certain intrinsics.
extern compiler_builtins;

#[link(name = "c")]
extern {}

// Each of these functions lowers to one of the intrinsics that we want to make sure that
// compiler_builtins provide.
fn mulodi4(a: i64, b: i64) -> i64 {
    a.overflowing_mul(b)
}

fn aeabi_uldivmod(a: u64, b: u64) -> u64 {
    a * b
}

// We need to use the above functions in "main" so they make it to the final binary
#[start]
fn start(_: isize, _: *const *const u8) -> isize {
    mulodi4(2, 3);
    aeabi_uldivmod(2, 3);

    0
}

If, by mistake, compiler_builtins stops providing an intrinsic like __mulodi4 then the above
program will fail to link with message like this:

$ rustc --target arm-unknown-linux-gnueabi -C linker=arm-linux-gnueabi-gcc intrinsics.rs
error: linking with `arm-linux-gnueabi-gcc` failed: exit code: 1
  |
  = note: intrinsics.0.o: In function `core::num::_$LT$impl$u20$i64$GT$::overflowing_mul::he2cc89f0220146d6':
intrinsics.cgu-0.rs:(.text._ZN4core3num21_$LT$impl$u20$i64$GT$15overflowing_mul17he2cc89f0220146d6E+0x4c): undefined reference to `__mulodi4'

So, in a sense, this is a link-pass test :-).

We'll have to update our testing machinery to compile this program for all targets and cross
targets, even if we only provide std for them, via some make invocation.

The tricky bit of this approach is that we have to figure out how make the program above include all
the intrinsics we are interested in testing. In some cases, an arithmetic expression lowers to an
intrinsic if the target doesn't support the operation natively (see mulodi and aeabi_uldivmod in
the program above). But, I'm not sure if we can generate all the intrinsics we care about that way (I
hope so though).

cc @alexcrichton @brson
blocks #35437

[japaric]

smoke is an excellent place to test this. It can test the intrinsics.rs approach for ~20 targets right now.

[japaric]

Ok, landed intrinsics.rs in japaric-archived/smoke#26. It checks for the presence of 16 intrinsics right now but we probably use way more than just those. I'll continue expanding the coverage.

[alexcrichton]

This sounds like a great idea to me, and I'd love to have it!

I wonder if this could perhaps just be part of cargo test for the compiler-builtins crate? We could just do cargo test --no-run for targets we can't actually run perhaps?

[alexcrichton]

I believe this is effectively done upstream, so closing.