Bad codegen (most probably) on ARMv7

[stjepang]

The build for PR #42882 failed on ARM machines only. The failure is baffling and makes no sense at all. I managed to reproduce it on my Raspberry Pi and then tried minimizing the code bit by bit. This is the smallest example I have that demonstrates the problem:

#![feature(rand)]

use std::__rand::thread_rng;
use std::sync::atomic::{ATOMIC_USIZE_INIT, AtomicUsize, Ordering};

static GLOBAL: AtomicUsize = ATOMIC_USIZE_INIT;

struct Foo(usize);

impl Drop for Foo {
    fn drop(&mut self) {
        assert!(self.0 == 0);
        GLOBAL.fetch_add(0, Ordering::Relaxed);
        GLOBAL.fetch_add(0, Ordering::Relaxed);
    }
}

fn main() {
    let len = 1;

    for &modulus in &[100, 100] {
        println!("len = {}, modulus = {}", len, modulus);

        let _rng = thread_rng();

        (0..len).map(|_| Foo(0 % modulus)).collect::<Vec<_>>();
    }
}

Running in debug mode is all right:

     Running `target/debug/vector-sort-panic-safe`
len = 1, modulus = 100
len = 1, modulus = 100

But running in release mode prints out weird stuff:

     Running `target/release/vector-sort-panic-safe`
len = 1, modulus = 100
len = 1, modulus = 100
len = 1, modulus = 3785379840
len = 1, modulus = 3800891488
len = 1, modulus = 3959422609
len = 1, modulus = 3800891468
len = 1, modulus = 3959422587
len = 1, modulus = 3785359365
len = 1, modulus = 3959422388
len = 1, modulus = 3785379840
len = 1, modulus = 3942645753
len = 1, modulus = 100
len = 1, modulus = 100

Environment:

$ rustc --version
rustc 1.20.0-nightly (c9bb93576 2017-06-24)
$ cargo --version
cargo 0.21.0-nightly (d26fd6f08 2017-06-20)
$ uname -a
Linux raspberrypi 4.4.11-v7+ #888 SMP Mon May 23 20:10:33 BST 2016 armv7l GNU/Linux

cc @alexcrichton

[Mark-Simulacrum]

cc @arielb1 -- seems there's perhaps more to fix, even after #42740.

[arielb1]

Let me take a look

[arielb1]

This is supposed to occur on armv7-unknown-linux-gnueabihf or on armv6?

[stjepang]

It's on armv7-unknown-linux-gnueabihf

[arielb1]

Bug confirmed.

[arielb1]

This looks fixed on LLVM 5.0, looks like we need another bisect run.

[arielb1]

Looks like 4868a15090d0dbaa91b772e498eadc92cfdebd7a - [ARM] Temporarily disable globals promotion to constant pools to prevent miscompilation. That is going into LLVM 4.0.1, so we might just get that.

LLVM 4.0.1 is actually just 21 commits:

[mips][mc] Fix a crash when disassembling odd sized sections
Use correct registers for "A" inline asm constraint
[X86] Remove special handling for 16 bit for A asm constraints.
Fix invalid addrspacecast due to combining alloca with global var
Adding const overloads of operator* and operator-> for DenseSet iterators
[Hexagon] Fix lowering of formal arguments of type i1
[InstCombine] Fix bug in pointer replacement
[CMake] Fix pthread handling for out-of-tree builds
CMake: Don't install llvm-tblgen twice
[MemCpyOpt] Only replace memcpy with bitcast if address spaces match
[ArgPromotion] Fix a truncated variable
[safestack] Disable stack coloring by default
merge-request.sh: Use https url for bugzilla
[ARM] Clear the constant pool cache on explicit .ltorg directives
[ARM] Temporarily disable globals promotion to constant pools to prevent miscompilation
[TLI] Add prototype checking for all remaining LibFuncs
[PPC] Properly update register save area offset
[PPC] When restoring R30 (PIC base pointer), mark it as <def>
Make library calls sensitive to regparm module flag (Fixes PR3997).
[GlobalMerge] Don't merge globals that may be preempted
[Support] Fix ErrorOr assertion when /proc/cpuinfo doesn't exist.