Auto merge of #40123 - TimNN:llvm40, r=TimNN

LLVM 4.0 Upgrade

Since nobody has done this yet, I decided to get things started:

**Todo:**

* [x] push the relevant commits to `rust-lang/llvm` and `rust-lang/compiler-rt`
* [x] cleanup `.gitmodules`
* [ ] Verify if there are any other commits from `rust-lang/llvm` which need backporting
* [x] Investigate / fix debuginfo ("`<optimized out>`") failures
* [x] Use correct emscripten version in docker image

---

Closes #37609.

---

**Test results:**

* Travis (full build) is green
* Local Windows build was green
* Appveyor Windows build segfaults while running `llvm-tablegen`, investigating.

appveyor.yml

@@ -20,39 +20,28 @@ environment:
 
   # 32/64-bit MinGW builds.
   #
-  # The MinGW builds unfortunately have to both download a custom toolchain and
-  # avoid the one installed by AppVeyor by default. Interestingly, though, for
-  # different reasons!
+  # We are using MinGW with posix threads since LLVM does not compile with
+  # the win32 threads version due to missing support for C++'s std::thread.
   #
-  # For 32-bit the installed gcc toolchain on AppVeyor uses the pthread
-  # threading model. This is unfortunately not what we want, and if we compile
-  # with it then there's lots of link errors in the standard library (undefined
-  # references to pthread symbols).
-  #
-  # For 64-bit the installed gcc toolchain is currently 5.3.0 which
-  # unfortunately segfaults on Windows with --enable-llvm-assertions (segfaults
-  # in LLVM). See rust-lang/rust#28445 for more information, but to work around
-  # this we go back in time to 4.9.2 specifically.
+  # Instead of relying on the MinGW version installed on appveryor we download
+  # and install one ourselves so we won't be surprised by changes to appveyor's
+  # build image.
   #
   # Finally, note that the downloads below are all in the `rust-lang-ci` S3
   # bucket, but they cleraly didn't originate there! The downloads originally
   # came from the mingw-w64 SourceForge download site. Unfortunately
   # SourceForge is notoriously flaky, so we mirror it on our own infrastructure.
-  #
-  # And as a final point of note, the 32-bit MinGW build using the makefiles do
-  # *not* use debug assertions and llvm assertions. This is because they take
-  # too long on appveyor and this is tested by rustbuild below.
   - MSYS_BITS: 32
     RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-ninja
     SCRIPT: python x.py test
     MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror
-    MINGW_ARCHIVE: i686-6.2.0-release-win32-dwarf-rt_v5-rev1.7z
+    MINGW_ARCHIVE: i686-6.2.0-release-posix-dwarf-rt_v5-rev1.7z
     MINGW_DIR: mingw32
   - MSYS_BITS: 64
     SCRIPT: python x.py test
     RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-ninja
     MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror
-    MINGW_ARCHIVE: x86_64-6.2.0-release-win32-seh-rt_v5-rev1.7z
+    MINGW_ARCHIVE: x86_64-6.2.0-release-posix-seh-rt_v5-rev1.7z
     MINGW_DIR: mingw64
 
   # 32/64 bit MSVC and GNU deployment
@@ -71,14 +60,14 @@ environment:
     RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-extended --enable-ninja
     SCRIPT: python x.py dist
     MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror
-    MINGW_ARCHIVE: i686-6.2.0-release-win32-dwarf-rt_v5-rev1.7z
+    MINGW_ARCHIVE: i686-6.2.0-release-posix-dwarf-rt_v5-rev1.7z
     MINGW_DIR: mingw32
     DEPLOY: 1
   - MSYS_BITS: 64
     SCRIPT: python x.py dist
     RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-extended --enable-ninja
     MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror
-    MINGW_ARCHIVE: x86_64-6.2.0-release-win32-seh-rt_v5-rev1.7z
+    MINGW_ARCHIVE: x86_64-6.2.0-release-posix-seh-rt_v5-rev1.7z
     MINGW_DIR: mingw64
     DEPLOY: 1
 
@@ -146,6 +135,7 @@ test_script:
   - set SRC=.
   - set NO_CCACHE=1
   - sh src/ci/run.sh
+  - exit 1
 
 on_failure:
   - cat %CD%\sccache.log || exit 0

src/bootstrap/lib.rs

@@ -877,6 +877,13 @@ impl Build {
         if target.contains("apple-darwin") {
             base.push("-stdlib=libc++".into());
         }
+
+        // Work around an apparently bad MinGW / GCC optimization,
+        // See: http://lists.llvm.org/pipermail/cfe-dev/2016-December/051980.html
+        // See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78936
+        if target == "i686-pc-windows-gnu" {
+            base.push("-fno-omit-frame-pointer".into());
+        }
         return base
     }
 

src/ci/docker/emscripten/Dockerfile

@@ -27,10 +27,10 @@ WORKDIR /tmp
 COPY build-emscripten.sh /tmp/
 RUN ./build-emscripten.sh
 ENV PATH=$PATH:/tmp/emsdk_portable
-ENV PATH=$PATH:/tmp/emsdk_portable/clang/tag-e1.37.1/build_tag-e1.37.1_32/bin
+ENV PATH=$PATH:/tmp/emsdk_portable/clang/tag-e1.37.8/build_tag-e1.37.8_32/bin
 ENV PATH=$PATH:/tmp/emsdk_portable/node/4.1.1_32bit/bin
-ENV PATH=$PATH:/tmp/emsdk_portable/emscripten/tag-1.37.1
-ENV EMSCRIPTEN=/tmp/emsdk_portable/emscripten/tag-1.37.1
+ENV PATH=$PATH:/tmp/emsdk_portable/emscripten/tag-1.37.8
+ENV EMSCRIPTEN=/tmp/emsdk_portable/emscripten/tag-1.37.8
 
 ENV RUST_CONFIGURE_ARGS --target=asmjs-unknown-emscripten
 

src/ci/docker/emscripten/build-emscripten.sh

@@ -49,5 +49,5 @@ chmod 755 emsdk_portable
 
 source emsdk_portable/emsdk_env.sh
 hide_output emsdk update
-hide_output emsdk install --build=Release sdk-tag-1.37.1-32bit
-hide_output emsdk activate --build=Release sdk-tag-1.37.1-32bit
+hide_output emsdk install --build=Release sdk-tag-1.37.8-32bit
+hide_output emsdk activate --build=Release sdk-tag-1.37.8-32bit

src/libcompiler_builtins/build.rs

@@ -293,6 +293,12 @@ fn main() {
     }
 
     if target.contains("arm") && !target.contains("ios") {
+        // (At least) udivsi3.S is broken for Thumb 1 which our gcc uses by
+        // default, we don't want Thumb 2 since it isn't supported on some
+        // devices, so disable thumb entirely.
+        // Upstream bug: https://bugs.llvm.org/show_bug.cgi?id=32492
+        cfg.define("__ARM_ARCH_ISA_THUMB", Some("0"));
+
         sources.extend(&["arm/aeabi_cdcmp.S",
                          "arm/aeabi_cdcmpeq_check_nan.c",
                          "arm/aeabi_cfcmp.S",

src/librustc_llvm/build.rs

@@ -268,4 +268,8 @@ fn main() {
     if target.contains("windows") {
         println!("cargo:rustc-link-lib=ole32");
     }
+    if target.contains("windows-gnu") {
+        println!("cargo:rustc-link-lib=static-nobundle=gcc_s");
+        println!("cargo:rustc-link-lib=static-nobundle=pthread");
+    }
 }

src/librustc_llvm/lib.rs

@@ -29,6 +29,7 @@
 #![feature(link_args)]
 #![feature(staged_api)]
 #![feature(rustc_private)]
+#![feature(static_nobundle)]
 
 extern crate libc;
 #[macro_use]

src/test/run-pass/issue-29663.rs

@@ -10,6 +10,8 @@
 
 // write_volatile causes an LLVM assert with composite types
 
+// ignore-emscripten See #41299: probably a bad optimization
+
 #![feature(volatile)]
 use std::ptr::{read_volatile, write_volatile};
 

src/test/run-pass/panic-runtime/abort-link-to-unwinding-crates.rs

@@ -27,7 +27,17 @@ fn main() {
             exit_success_if_unwind::bar(do_panic);
         }
     }
-    let s = Command::new(env::args_os().next().unwrap()).arg("foo").status();
+
+    let mut cmd = Command::new(env::args_os().next().unwrap());
+    cmd.arg("foo");
+
+
+    // ARMv6 hanges while printing the backtrace, see #41004
+    if cfg!(target_arch = "arm") && cfg!(target_env = "gnu") {
+        cmd.env("RUST_BACKTRACE", "0");
+    }
+
+    let s = cmd.status();
     assert!(s.unwrap().code() != Some(0));
 }
 

src/test/run-pass/panic-runtime/abort.rs

@@ -35,6 +35,15 @@ fn main() {
             panic!("try to catch me");
         }
     }
-    let s = Command::new(env::args_os().next().unwrap()).arg("foo").status();
+
+    let mut cmd = Command::new(env::args_os().next().unwrap());
+    cmd.arg("foo");
+
+    // ARMv6 hanges while printing the backtrace, see #41004
+    if cfg!(target_arch = "arm") && cfg!(target_env = "gnu") {
+        cmd.env("RUST_BACKTRACE", "0");
+    }
+
+    let s = cmd.status();
     assert!(s.unwrap().code() != Some(0));
 }