New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

LLVM 4.0 Upgrade #40123

Merged
merged 12 commits into from Apr 25, 2017

Conversation

Projects
None yet
@TimNN
Contributor

TimNN commented Feb 27, 2017

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

Todo:

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

Closes #37609.


Test results:

Everything is green 馃帀

@rust-highfive

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Feb 27, 2017

Collaborator

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

Collaborator

rust-highfive commented Feb 27, 2017

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Feb 27, 2017

Member

@TimNN you can probably work faster than going through @bors by selectively adding ALLOW_PR=1 to various entries in .travis.yml, that'll run the tests on the PR itself before we hit @bors.

I'd recommend doing that for a couple of the cross targets at least and then probably some of the other builders as well (such as emscripten)

My guess is that AppVeyor will be one of the most difficult pieces to update as part of this upgrade. Unfortunately we don't have any extra capacity there for running tests so it may be difficult to do so on the PR before bors :(

Member

alexcrichton commented Feb 27, 2017

@TimNN you can probably work faster than going through @bors by selectively adding ALLOW_PR=1 to various entries in .travis.yml, that'll run the tests on the PR itself before we hit @bors.

I'd recommend doing that for a couple of the cross targets at least and then probably some of the other builders as well (such as emscripten)

My guess is that AppVeyor will be one of the most difficult pieces to update as part of this upgrade. Unfortunately we don't have any extra capacity there for running tests so it may be difficult to do so on the PR before bors :(

@TimNN

This comment has been minimized.

Show comment
Hide comment
@TimNN

TimNN Feb 27, 2017

Contributor

The debuginfo failures all occur because static muts are optimized out. (I verified that no optimisation flags were passed to rustc).

I'm unsure what the best fix would be here (something like the #[used] attribute from #39987 would probably work).

Contributor

TimNN commented Feb 27, 2017

The debuginfo failures all occur because static muts are optimized out. (I verified that no optimisation flags were passed to rustc).

I'm unsure what the best fix would be here (something like the #[used] attribute from #39987 would probably work).

@rkruppe

This comment has been minimized.

Show comment
Hide comment
@rkruppe

rkruppe Feb 27, 2017

Contributor

static muts getting optimized out sounds like an issue with the IR/debug info we generate. Perhaps one of the debug info-related changes was incomplete and we don't emit everything we need to emit for globals? (#39528 looks very related.) To clarify, does this:

static muts are optimized out

mean that gdb outputs <optimized out>, or did you check the object files and the symbols for the globals were missing?

In any case, requiring #[used] on static muts to enable debugging would be a serious regression, not to mention that #[used] doesn't exist yet and I'm not even sure it would fix this (see above).

Contributor

rkruppe commented Feb 27, 2017

static muts getting optimized out sounds like an issue with the IR/debug info we generate. Perhaps one of the debug info-related changes was incomplete and we don't emit everything we need to emit for globals? (#39528 looks very related.) To clarify, does this:

static muts are optimized out

mean that gdb outputs <optimized out>, or did you check the object files and the symbols for the globals were missing?

In any case, requiring #[used] on static muts to enable debugging would be a serious regression, not to mention that #[used] doesn't exist yet and I'm not even sure it would fix this (see above).

@petrochenkov

This comment has been minimized.

Show comment
Hide comment
@petrochenkov

petrochenkov Feb 27, 2017

Contributor

I vaguely remember about statics being optimized away the last summer already, when I wrote debuginfo tests for unions (one of the failing tests in this PR).
So I had to add at least an assignment for the static to be kept.
Maybe the LLVM optimizer become better and now sees that the optimization is still possible?

Contributor

petrochenkov commented Feb 27, 2017

I vaguely remember about statics being optimized away the last summer already, when I wrote debuginfo tests for unions (one of the failing tests in this PR).
So I had to add at least an assignment for the static to be kept.
Maybe the LLVM optimizer become better and now sees that the optimization is still possible?

@TimNN

This comment has been minimized.

Show comment
Hide comment
@TimNN

TimNN Feb 27, 2017

Contributor

To clarify, does this:

static muts are optimized out

mean that gdb outputs <optimized out>, or did you check the object files and the symbols for the globals were missing?

It means that gdb prints <optimized out>

Apparently I made some assumptions that weren't quite correct.

The symbols exist (output of nm from the simple-struct test:

0000000000201008 d _ZN13simple_struct13NO_PADDING_1617h8f8e1027ea816fe7E
000000000020100c d _ZN13simple_struct13NO_PADDING_3217h9e367c36ef03eabcE
0000000000201018 d _ZN13simple_struct13NO_PADDING_6417h3c4e19994ee55915E
0000000000201050 d _ZN13simple_struct14PADDING_AT_END17h210f8219dd75f271E
0000000000201040 d _ZN13simple_struct16INTERNAL_PADDING17he308dba4866e981bE
0000000000201030 d _ZN13simple_struct17NO_PADDING_16326417h136d93d95c4cf5b5E

Since this is apparently indeed debuginfo related I guess cc @michaelwoerister, @dylanmckay

Contributor

TimNN commented Feb 27, 2017

To clarify, does this:

static muts are optimized out

mean that gdb outputs <optimized out>, or did you check the object files and the symbols for the globals were missing?

It means that gdb prints <optimized out>

Apparently I made some assumptions that weren't quite correct.

The symbols exist (output of nm from the simple-struct test:

0000000000201008 d _ZN13simple_struct13NO_PADDING_1617h8f8e1027ea816fe7E
000000000020100c d _ZN13simple_struct13NO_PADDING_3217h9e367c36ef03eabcE
0000000000201018 d _ZN13simple_struct13NO_PADDING_6417h3c4e19994ee55915E
0000000000201050 d _ZN13simple_struct14PADDING_AT_END17h210f8219dd75f271E
0000000000201040 d _ZN13simple_struct16INTERNAL_PADDING17he308dba4866e981bE
0000000000201030 d _ZN13simple_struct17NO_PADDING_16326417h136d93d95c4cf5b5E

Since this is apparently indeed debuginfo related I guess cc @michaelwoerister, @dylanmckay

@TimNN

This comment has been minimized.

Show comment
Hide comment
@TimNN

TimNN Feb 27, 2017

Contributor

The generated IR, in case that helps anyone: https://gist.github.com/TimNN/92152a2f8062909805657d1bb4131998

Contributor

TimNN commented Feb 27, 2017

The generated IR, in case that helps anyone: https://gist.github.com/TimNN/92152a2f8062909805657d1bb4131998

@TimNN

This comment has been minimized.

Show comment
Hide comment
@TimNN

TimNN Feb 27, 2017

Contributor

The failed build of the IMAGE=cross seems to be qemu related, one of the failed tests:

---- [run-pass] run-pass/alignment-gep-tup-like-1.rs stdout ----
	
error: test run failed!
status: exit code: 101
command: /checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools/x86_64-unknown-linux-gnu/release/qemu-test-client run /checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass/alignment-gep-tup-like-1.stage2-arm-unknown-linux-gnueabihf
stdout:
------------------------------------------
uploaded "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass/alignment-gep-tup-like-1.stage2-arm-unknown-linux-gnueabihf", waiting for result
a=22 b=44

------------------------------------------
stderr:
------------------------------------------
thread 'main' panicked at 'client.read_exact(&mut header) failed with failed to fill whole buffer', /checkout/src/tools/qemu-test-client/src/main.rs:174
note: Run with `RUST_BACKTRACE=1` for a backtrace.

------------------------------------------

thread '[run-pass] run-pass/alignment-gep-tup-like-1.rs' panicked at 'explicit panic', /checkout/src/tools/compiletest/src/runtest.rs:2637
note: Run with `RUST_BACKTRACE=1` for a backtrace.

I saw the following panics:

     61 thread 'main' panicked at 'client.read_exact(&mut header) failed with Connection reset by peer (os error 104)', /checkout/src/tools/qemu-test-client/src/main.rs:174
      3 thread 'main' panicked at 'client.read_exact(&mut header) failed with failed to fill whole buffer', /checkout/src/tools/qemu-test-client/src/main.rs:174
      1 thread 'main' panicked at 'io::copy(&mut file, dst) failed I/O failure during tests: Error { repr: Os { code: 11, message: "Resource temporarily unavailable" } }
     96 thread 'main' panicked at 'io::copy(&mut file, dst) failed with Broken pipe (os error 32)', /checkout/src/tools/qemu-test-client/src/main.rs:220
      1 thread 'main' panicked at 'io::copy(&mut file, dst) failed with Connection reset by peer (os error 104)', /checkout/src/tools/qemu-test-client/src/main.rs:220

Do they ring a bell for anyone?

Contributor

TimNN commented Feb 27, 2017

The failed build of the IMAGE=cross seems to be qemu related, one of the failed tests:

---- [run-pass] run-pass/alignment-gep-tup-like-1.rs stdout ----
	
error: test run failed!
status: exit code: 101
command: /checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools/x86_64-unknown-linux-gnu/release/qemu-test-client run /checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass/alignment-gep-tup-like-1.stage2-arm-unknown-linux-gnueabihf
stdout:
------------------------------------------
uploaded "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass/alignment-gep-tup-like-1.stage2-arm-unknown-linux-gnueabihf", waiting for result
a=22 b=44

------------------------------------------
stderr:
------------------------------------------
thread 'main' panicked at 'client.read_exact(&mut header) failed with failed to fill whole buffer', /checkout/src/tools/qemu-test-client/src/main.rs:174
note: Run with `RUST_BACKTRACE=1` for a backtrace.

------------------------------------------

thread '[run-pass] run-pass/alignment-gep-tup-like-1.rs' panicked at 'explicit panic', /checkout/src/tools/compiletest/src/runtest.rs:2637
note: Run with `RUST_BACKTRACE=1` for a backtrace.

I saw the following panics:

     61 thread 'main' panicked at 'client.read_exact(&mut header) failed with Connection reset by peer (os error 104)', /checkout/src/tools/qemu-test-client/src/main.rs:174
      3 thread 'main' panicked at 'client.read_exact(&mut header) failed with failed to fill whole buffer', /checkout/src/tools/qemu-test-client/src/main.rs:174
      1 thread 'main' panicked at 'io::copy(&mut file, dst) failed I/O failure during tests: Error { repr: Os { code: 11, message: "Resource temporarily unavailable" } }
     96 thread 'main' panicked at 'io::copy(&mut file, dst) failed with Broken pipe (os error 32)', /checkout/src/tools/qemu-test-client/src/main.rs:220
      1 thread 'main' panicked at 'io::copy(&mut file, dst) failed with Connection reset by peer (os error 104)', /checkout/src/tools/qemu-test-client/src/main.rs:220

Do they ring a bell for anyone?

@TimNN

This comment has been minimized.

Show comment
Hide comment
@TimNN

TimNN Feb 27, 2017

Contributor

The emscripten failure are mainly of the kind Invalid record (Producer: 'LLVM4.0.0' Reader: 'LLVM 3.9.0'), although there are some assertion failures as well. (I would fix the llvm version mismatch first, maybe that fixes the assertion failures as well).

Contributor

TimNN commented Feb 27, 2017

The emscripten failure are mainly of the kind Invalid record (Producer: 'LLVM4.0.0' Reader: 'LLVM 3.9.0'), although there are some assertion failures as well. (I would fix the llvm version mismatch first, maybe that fixes the assertion failures as well).

@TimNN

This comment has been minimized.

Show comment
Hide comment
@TimNN

TimNN Feb 27, 2017

Contributor

The android image fails with an LLVM assertion:

rustc: /checkout/src/llvm/lib/Target/ARM/ARMConstantIslandPass.cpp:492: void {anonymous}::ARMConstantIslands::doInitialConstPlacement(std::vector<llvm::MachineInstr*>&): Assertion `Size >= 4 && "Too small constant pool entry"' failed.
Build failed, waiting for other jobs to finish...
rustc: /checkout/src/llvm/lib/Target/ARM/ARMConstantIslandPass.cpp:492: void {anonymous}::ARMConstantIslands::doInitialConstPlacement(std::vector<llvm::MachineInstr*>&): Assertion `Size >= 4 && "Too small constant pool entry"' failed.
error: Could not compile `core`.

There are also some warnings (see below for an example), of which I am unsure how relevant / important they are.

warning: ../compiler-rt/lib/builtins/mulsc3.c:21:1: warning: conflicting types for built-in function '__mulsc3'
warning:  __mulsc3(float __a, float __b, float __c, float __d)
warning:  ^
Contributor

TimNN commented Feb 27, 2017

The android image fails with an LLVM assertion:

rustc: /checkout/src/llvm/lib/Target/ARM/ARMConstantIslandPass.cpp:492: void {anonymous}::ARMConstantIslands::doInitialConstPlacement(std::vector<llvm::MachineInstr*>&): Assertion `Size >= 4 && "Too small constant pool entry"' failed.
Build failed, waiting for other jobs to finish...
rustc: /checkout/src/llvm/lib/Target/ARM/ARMConstantIslandPass.cpp:492: void {anonymous}::ARMConstantIslands::doInitialConstPlacement(std::vector<llvm::MachineInstr*>&): Assertion `Size >= 4 && "Too small constant pool entry"' failed.
error: Could not compile `core`.

There are also some warnings (see below for an example), of which I am unsure how relevant / important they are.

warning: ../compiler-rt/lib/builtins/mulsc3.c:21:1: warning: conflicting types for built-in function '__mulsc3'
warning:  __mulsc3(float __a, float __b, float __c, float __d)
warning:  ^
@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Feb 27, 2017

Member

@TimNN the former may be a bug in LLVM? (or just something we've never exposed ourselves before). The latter is normal, I believe it's happening on builds today.

Member

alexcrichton commented Feb 27, 2017

@TimNN the former may be a bug in LLVM? (or just something we've never exposed ourselves before). The latter is normal, I believe it's happening on builds today.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Feb 27, 2017

Member

Oh we've also got ~10 extra capacity on Travis so feel free to test more than one row at a time if you'd like :)

Member

alexcrichton commented Feb 27, 2017

Oh we've also got ~10 extra capacity on Travis so feel free to test more than one row at a time if you'd like :)

@TimNN

This comment has been minimized.

Show comment
Hide comment
@TimNN

TimNN Feb 28, 2017

Contributor

@alexcrichton: Have you ever seen something like the qemu failures in #40123 (comment) before?

Oh we've also got ~10 extra capacity on Travis so feel free to test more than one row at a time if you'd like :)

Ah, ok. I've been doing 3 at a time (when not debugging emscripten), but I guess I can run a few more :)

Contributor

TimNN commented Feb 28, 2017

@alexcrichton: Have you ever seen something like the qemu failures in #40123 (comment) before?

Oh we've also got ~10 extra capacity on Travis so feel free to test more than one row at a time if you'd like :)

Ah, ok. I've been doing 3 at a time (when not debugging emscripten), but I guess I can run a few more :)

@TimNN

This comment has been minimized.

Show comment
Hide comment
@TimNN

TimNN Feb 28, 2017

Contributor

The dist-s390x-linux-netbsd build fails while cross compiling llvm due to missing std::thread support:

In file included from /checkout/src/llvm/include/llvm/Support/ThreadPool.h:17:0,
                 from /checkout/src/llvm/lib/Support/ThreadPool.cpp:14:
/checkout/src/llvm/include/llvm/Support/thread.h:41:14: error: 'thread' in namespace 'std' does not name a type
 typedef std::thread thread;

I guess the fix here is to backport (part of?) rust-lang/llvm@58731be as well.

Contributor

TimNN commented Feb 28, 2017

The dist-s390x-linux-netbsd build fails while cross compiling llvm due to missing std::thread support:

In file included from /checkout/src/llvm/include/llvm/Support/ThreadPool.h:17:0,
                 from /checkout/src/llvm/lib/Support/ThreadPool.cpp:14:
/checkout/src/llvm/include/llvm/Support/thread.h:41:14: error: 'thread' in namespace 'std' does not name a type
 typedef std::thread thread;

I guess the fix here is to backport (part of?) rust-lang/llvm@58731be as well.

@TimNN

This comment has been minimized.

Show comment
Hide comment
@TimNN

TimNN Feb 28, 2017

Contributor

I've been investigating the emscripten failures, see below for the findings. The one thing that both test have in common is that they use fixed sized arrays ([constexpr; len]) although if that is related / the problem, I don't know.

  • run-pass/packed-struct-vec.rs IR:

The #[repr(packed)] seems to be just broken, printing instead of asserting for equality gives the following results:

Foo { bar: 2, baz: 2 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 0, baz: 2 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 0, baz: 2 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 1, baz: 2 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 2, baz: 2 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 0, baz: 2 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 0, baz: 2 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 1, baz: 2 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 2, baz: 2 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 0, baz: 2 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 0, baz: 144115188075855872 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 0, baz: 562949953421312 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 0, baz: 0 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 2, baz: 2 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 0, baz: 144115188075855872 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 0, baz: 562949953421312 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 0, baz: 0 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 2, baz: 2 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 0, baz: 144115188075855872 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 0, baz: 0 }, Foo { bar: 1, baz: 33649522 }

(with this code:)

use std::mem;

#[repr(packed)]
#[derive(Copy, Clone, PartialEq, Debug)]
struct Foo {
    bar: u8,
    baz: u64
}

pub fn main() {
    let foos = [Foo { bar: 1, baz: 2 }; 10];

    assert_eq!(mem::size_of::<[Foo; 10]>(), 90);

    for i in 0..10 {
        println!("{:?}, {:?}", foos[i], Foo { bar: 1, baz: 2});
    }

    for &foo in &foos {
        println!("{:?}, {:?}", foo, Foo { bar: 1, baz: 2 });
    }

    assert!(false);
}
  • run-pass/issue-29663.rs IR:

The write_volatile in the following snippet is apparently not executed correctly:

        let mut x = E([0; 32]);
        write_volatile(&mut x, E([1; 32]));
        assert_eq!(read_volatile(&x), E([1; 32])); // line 61
        assert_eq!(x, E([1; 32]));                 // line 62

The output:

thread 'main' panicked at 'assertion failed: `(left == right)` (left: `E([0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0])`, right: `E([1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1])`)', /checkout/src/test/run-pass/issue-29663.rs:61

If line 61 is commented:

thread 'main' panicked at 'assertion failed: `(left == right)` (left: `E([0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1])`, right: `E([1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1])`)', /checkout/src/test/run-pass/issue-29663.rs:62

Note that other write_volatile / read_volatile pairs work correctly.

Contributor

TimNN commented Feb 28, 2017

I've been investigating the emscripten failures, see below for the findings. The one thing that both test have in common is that they use fixed sized arrays ([constexpr; len]) although if that is related / the problem, I don't know.

  • run-pass/packed-struct-vec.rs IR:

The #[repr(packed)] seems to be just broken, printing instead of asserting for equality gives the following results:

Foo { bar: 2, baz: 2 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 0, baz: 2 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 0, baz: 2 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 1, baz: 2 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 2, baz: 2 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 0, baz: 2 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 0, baz: 2 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 1, baz: 2 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 2, baz: 2 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 0, baz: 2 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 0, baz: 144115188075855872 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 0, baz: 562949953421312 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 0, baz: 0 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 2, baz: 2 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 0, baz: 144115188075855872 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 0, baz: 562949953421312 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 0, baz: 0 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 2, baz: 2 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 0, baz: 144115188075855872 }, Foo { bar: 1, baz: 33649522 }
Foo { bar: 0, baz: 0 }, Foo { bar: 1, baz: 33649522 }

(with this code:)

use std::mem;

#[repr(packed)]
#[derive(Copy, Clone, PartialEq, Debug)]
struct Foo {
    bar: u8,
    baz: u64
}

pub fn main() {
    let foos = [Foo { bar: 1, baz: 2 }; 10];

    assert_eq!(mem::size_of::<[Foo; 10]>(), 90);

    for i in 0..10 {
        println!("{:?}, {:?}", foos[i], Foo { bar: 1, baz: 2});
    }

    for &foo in &foos {
        println!("{:?}, {:?}", foo, Foo { bar: 1, baz: 2 });
    }

    assert!(false);
}
  • run-pass/issue-29663.rs IR:

The write_volatile in the following snippet is apparently not executed correctly:

        let mut x = E([0; 32]);
        write_volatile(&mut x, E([1; 32]));
        assert_eq!(read_volatile(&x), E([1; 32])); // line 61
        assert_eq!(x, E([1; 32]));                 // line 62

The output:

thread 'main' panicked at 'assertion failed: `(left == right)` (left: `E([0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0])`, right: `E([1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1])`)', /checkout/src/test/run-pass/issue-29663.rs:61

If line 61 is commented:

thread 'main' panicked at 'assertion failed: `(left == right)` (left: `E([0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1])`, right: `E([1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1])`)', /checkout/src/test/run-pass/issue-29663.rs:62

Note that other write_volatile / read_volatile pairs work correctly.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Feb 28, 2017

Member

@TimNN

The QEMU failures don't look familiar but are perhaps indicative of the program segfaulting or otherwise exiting un-cleanly. Do you have the full logs I could help take a look at?

The missing std::thread business may be related to how we compile compilers. It may be that one of our compilers is too old or something like that. I know that MinGW C++ compilers, at least, do not have std::thread (at least if I'm remembering correctly). Historically we've "dealt" with this by just deleting code that uses std::thread, but it's clearly getting harder over time! This also isn't scalable into the future really. Unfortunately I don't know of a great solution here.

Member

alexcrichton commented Feb 28, 2017

@TimNN

The QEMU failures don't look familiar but are perhaps indicative of the program segfaulting or otherwise exiting un-cleanly. Do you have the full logs I could help take a look at?

The missing std::thread business may be related to how we compile compilers. It may be that one of our compilers is too old or something like that. I know that MinGW C++ compilers, at least, do not have std::thread (at least if I'm remembering correctly). Historically we've "dealt" with this by just deleting code that uses std::thread, but it's clearly getting harder over time! This also isn't scalable into the future really. Unfortunately I don't know of a great solution here.

@TimNN

This comment has been minimized.

Show comment
Hide comment
@TimNN

TimNN Feb 28, 2017

Contributor

The QEMU failures don't look familiar but are perhaps indicative of the program segfaulting or otherwise exiting un-cleanly. Do you have the full logs I could help take a look at?

Ah, sorry, I linked the logs only from the original post, here they are: https://travis-ci.org/rust-lang/rust/jobs/205860539

Contributor

TimNN commented Feb 28, 2017

The QEMU failures don't look familiar but are perhaps indicative of the program segfaulting or otherwise exiting un-cleanly. Do you have the full logs I could help take a look at?

Ah, sorry, I linked the logs only from the original post, here they are: https://travis-ci.org/rust-lang/rust/jobs/205860539

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Feb 28, 2017

Member

Fascinating! Unfortunately I may not be of much help. Also thanks for the links, I should have looked around for them! Of the failures so far:

  • armhf - this is really suspicious. In theory if qemu-test-server panics in any way we'd see it in the logs (as it doesn't daemonize that much or anything), but I'm not seeing anything. The errors mean that the server is prematurely closing the connection, but I'm not sure how that's possible without otherwise printing error information! It may be a bug in LLVM or related to the assertion failures, but it may also require more debugging the qemu instance itself :(

  • emscripten - looks like you're on top of these (maybe fastcomp regressions? maybe llvm regression? unsure myself...)

  • android - yeah looks like an LLVM bug? Although I wouldn't rule out invalid codegen on our side just yet.

  • s390x-netbsd - Ok so this specifically failed to compiled LLVM for NetBSD. This is our script to compile NetBSD gcc and I don't see anything immediately wrong that should compile the wrong C++. I wonder if the gcc options accidentally disable std::thread? Or maybe it's disabled somewhere else on NetBSD by default? Not sure why that happened :(

Some other tips I'd have is:

  • You can run docker images locally via ./src/ci/docker/run.sh $image_name which can help with debugging (e.g. avoiding going through Travis). That should in theory use the precise same environment as Travis modulo kernel and hardware.

  • For suspected LLVM bugs the best way (although certainly not the fastest way) that I know to work with them is to (a) get it to reproduce with a manual rustc invocation then (b) get it to reproduce with an opt invocation by using rustc to generate LLVM IR then switching to LLVM's tools and then (c) minimizing that IR as much as possible. If it's small enough then reporting a bug on LLVM's issue tracker is usually good for getting the issue fixed in a timely fashion.

Member

alexcrichton commented Feb 28, 2017

Fascinating! Unfortunately I may not be of much help. Also thanks for the links, I should have looked around for them! Of the failures so far:

  • armhf - this is really suspicious. In theory if qemu-test-server panics in any way we'd see it in the logs (as it doesn't daemonize that much or anything), but I'm not seeing anything. The errors mean that the server is prematurely closing the connection, but I'm not sure how that's possible without otherwise printing error information! It may be a bug in LLVM or related to the assertion failures, but it may also require more debugging the qemu instance itself :(

  • emscripten - looks like you're on top of these (maybe fastcomp regressions? maybe llvm regression? unsure myself...)

  • android - yeah looks like an LLVM bug? Although I wouldn't rule out invalid codegen on our side just yet.

  • s390x-netbsd - Ok so this specifically failed to compiled LLVM for NetBSD. This is our script to compile NetBSD gcc and I don't see anything immediately wrong that should compile the wrong C++. I wonder if the gcc options accidentally disable std::thread? Or maybe it's disabled somewhere else on NetBSD by default? Not sure why that happened :(

Some other tips I'd have is:

  • You can run docker images locally via ./src/ci/docker/run.sh $image_name which can help with debugging (e.g. avoiding going through Travis). That should in theory use the precise same environment as Travis modulo kernel and hardware.

  • For suspected LLVM bugs the best way (although certainly not the fastest way) that I know to work with them is to (a) get it to reproduce with a manual rustc invocation then (b) get it to reproduce with an opt invocation by using rustc to generate LLVM IR then switching to LLVM's tools and then (c) minimizing that IR as much as possible. If it's small enough then reporting a bug on LLVM's issue tracker is usually good for getting the issue fixed in a timely fashion.

@TimNN

This comment has been minimized.

Show comment
Hide comment
@TimNN

TimNN Feb 28, 2017

Contributor
  • You can run docker images locally via ./src/ci/docker/run.sh $image_name which can help with debugging (e.g. avoiding going through Travis). That should in theory use the precise same environment as Travis modulo kernel and hardware.

Yeah, I'm doing that right now :)

s390x-netbsd

Alright, so the problem is, I think, that the following ./configure check fails when compiling: checking for gthreads library... no

Contributor

TimNN commented Feb 28, 2017

  • You can run docker images locally via ./src/ci/docker/run.sh $image_name which can help with debugging (e.g. avoiding going through Travis). That should in theory use the precise same environment as Travis modulo kernel and hardware.

Yeah, I'm doing that right now :)

s390x-netbsd

Alright, so the problem is, I think, that the following ./configure check fails when compiling: checking for gthreads library... no

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Feb 28, 2017

Member

@TimNN heh yeah that'd do it! I wonder if some more headers need to be copied from the NetBSD base system or something like that? Unfortunately I forget now at this point where I got those instructions from to build a NetBSD cross-compiler...

Member

alexcrichton commented Feb 28, 2017

@TimNN heh yeah that'd do it! I wonder if some more headers need to be copied from the NetBSD base system or something like that? Unfortunately I forget now at this point where I got those instructions from to build a NetBSD cross-compiler...

@mattico

This comment has been minimized.

Show comment
Hide comment
@mattico

mattico Feb 28, 2017

Contributor

Those warnings aren't new. I forget the cause.
Edit: meaning the compiler-rt function signature warnings which seem to have disappeared...

Contributor

mattico commented Feb 28, 2017

Those warnings aren't new. I forget the cause.
Edit: meaning the compiler-rt function signature warnings which seem to have disappeared...

@TimNN

This comment has been minimized.

Show comment
Hide comment
@TimNN

TimNN Feb 28, 2017

Contributor

Some notes on the armhf-gnu image:

  • I (once) got the same LLVM assertion as on android, this went away when retrying the build. I'll try to get this to reliably reproduce.
  • The qemu connection errors happen non deterministically, as far as I can tell, example: run-pass ran successfully, incremental failed afterwards, after a retry all ofrun-pass failed.
  • Now I got a segfault... and no idea what actually segfaulted...
Contributor

TimNN commented Feb 28, 2017

Some notes on the armhf-gnu image:

  • I (once) got the same LLVM assertion as on android, this went away when retrying the build. I'll try to get this to reliably reproduce.
  • The qemu connection errors happen non deterministically, as far as I can tell, example: run-pass ran successfully, incremental failed afterwards, after a retry all ofrun-pass failed.
  • Now I got a segfault... and no idea what actually segfaulted...
@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Feb 28, 2017

Member

Odd! I wouldn't entirely rule out a bug in qemu-test-{client,server} FWIW

Member

alexcrichton commented Feb 28, 2017

Odd! I wouldn't entirely rule out a bug in qemu-test-{client,server} FWIW

@TimNN

This comment has been minimized.

Show comment
Hide comment
@TimNN

TimNN Mar 3, 2017

Contributor

First of all a small progress update: Of the 25 Docker based builds, 16 build without problems, 2 required (small) fixes, 2 timed out on travis but succeeded locally and 5 are currently broken. I'll investigate the broken images over the next days when I have the time.


Some notes on the android failure:

The arm-android image causes an llvm assertion:

rustc: /checkout/src/llvm/lib/Target/ARM/ARMConstantIslandPass.cpp:492: void {anonymous}::ARMConstantIslands::doInitialConstPlacement(std::vector<llvm::MachineInstr*>&): Assertion `Size >= 4 && "Too small constant pool entry"' failed.

This happens while compiling the coretest crate:

"/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--crate-name" "coretest" "/checkout/src/libcore/../libcoretest/lib.rs" "-C" "opt-level=2" "--test" "-C" "metadata=84b5aaef553ce96c" "-C" "extra-filename=-84b5aaef553ce96c" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/arm-linux-androideabi/release/deps" "--emit=dep-info,link" "--target" "arm-linux-androideabi" "-L" "dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/arm-linux-androideabi/release/deps" "-L" "dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/release/deps" "--extern" "core=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/arm-linux-androideabi/release/deps/libcore-cd0ca85e71f914ca.rlib" "--cfg" "stage2" "--sysroot" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2" "-Cprefer-dynamic" "-C" "debug-assertions=n"

While running llvm passes, full backtrace:

#0  0x00007ffff736d7ef in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff736f3ea in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff7365bb7 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007ffff7365c62 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00007ffff15c300e in (anonymous namespace)::ARMConstantIslands::doInitialConstPlacement(std::vector<llvm::MachineInstr*, std::allocator<llvm::MachineInstr*> >&) [clone .constprop.328] () from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_llvm-7c760c0d87163cbb.so
#5  0x00007ffff15c8908 in (anonymous namespace)::ARMConstantIslands::runOnMachineFunction(llvm::MachineFunction&) ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_llvm-7c760c0d87163cbb.so
#6  0x00007ffff1bb8ac5 in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_llvm-7c760c0d87163cbb.so
#7  0x00007ffff2458c13 in llvm::FPPassManager::runOnFunction(llvm::Function&) ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_llvm-7c760c0d87163cbb.so
#8  0x00007ffff2458cdc in llvm::FPPassManager::runOnModule(llvm::Module&) ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_llvm-7c760c0d87163cbb.so
#9  0x00007ffff245877d in llvm::legacy::PassManagerImpl::run(llvm::Module&) ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_llvm-7c760c0d87163cbb.so
#10 0x00007ffff0d69903 in LLVMRustWriteOutputFile ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_llvm-7c760c0d87163cbb.so
#11 0x00007ffff606d834 in rustc_trans::back::write::write_output_file::h713482cdaa178321 ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_trans-efa094249cef739c.so
#12 0x00007ffff606fd3f in rustc_trans::back::write::optimize_and_codegen::_$u7b$$u7b$closure$u7d$$u7d$::h1b757de20fba8b9a ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_trans-efa094249cef739c.so
#13 0x00007ffff6074c26 in rustc_trans::back::write::execute_work_item::hbc7cd39d8cd88c44 ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_trans-efa094249cef739c.so
#14 0x00007ffff607167a in rustc_trans::back::write::run_passes::h7cf08f2c47729966 ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_trans-efa094249cef739c.so
#15 0x00007ffff7b52353 in rustc_driver::driver::phase_5_run_llvm_passes::h7c9bbedc8969c4b3 ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-b65378ba5ffb99d4.so
#16 0x00007ffff7b18aa4 in rustc_driver::driver::compile_input::hf3e3aa4173908b86 ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-b65378ba5ffb99d4.so
#17 0x00007ffff7b646d6 in rustc_driver::run_compiler::h8f8d47f1d258a8a6 ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-b65378ba5ffb99d4.so
#18 0x00007ffff7a84115 in std::panicking::try::do_call::h206b9daee04f4ea2 ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-b65378ba5ffb99d4.so
#19 0x00007ffff77a8077 in __rust_maybe_catch_panic ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/libstd-9a66b6a343d52844.so
#20 0x00007ffff7aa0e62 in _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h5d196fbb3229f499 ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-b65378ba5ffb99d4.so
#21 0x00007ffff779d248 in std::sys::imp::thread::Thread::new::thread_start::h2c901daa88f3cb32 ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/libstd-9a66b6a343d52844.so
#22 0x00007fffeefda6ca in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#23 0x00007ffff74400af in clone () from /lib/x86_64-linux-gnu/libc.so.6

I will attempt to build llvm / rustc with debug info tomorrow to get some more information on what is going on.

Contributor

TimNN commented Mar 3, 2017

First of all a small progress update: Of the 25 Docker based builds, 16 build without problems, 2 required (small) fixes, 2 timed out on travis but succeeded locally and 5 are currently broken. I'll investigate the broken images over the next days when I have the time.


Some notes on the android failure:

The arm-android image causes an llvm assertion:

rustc: /checkout/src/llvm/lib/Target/ARM/ARMConstantIslandPass.cpp:492: void {anonymous}::ARMConstantIslands::doInitialConstPlacement(std::vector<llvm::MachineInstr*>&): Assertion `Size >= 4 && "Too small constant pool entry"' failed.

This happens while compiling the coretest crate:

"/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--crate-name" "coretest" "/checkout/src/libcore/../libcoretest/lib.rs" "-C" "opt-level=2" "--test" "-C" "metadata=84b5aaef553ce96c" "-C" "extra-filename=-84b5aaef553ce96c" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/arm-linux-androideabi/release/deps" "--emit=dep-info,link" "--target" "arm-linux-androideabi" "-L" "dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/arm-linux-androideabi/release/deps" "-L" "dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/release/deps" "--extern" "core=/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-std/arm-linux-androideabi/release/deps/libcore-cd0ca85e71f914ca.rlib" "--cfg" "stage2" "--sysroot" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2" "-Cprefer-dynamic" "-C" "debug-assertions=n"

While running llvm passes, full backtrace:

#0  0x00007ffff736d7ef in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff736f3ea in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff7365bb7 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007ffff7365c62 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00007ffff15c300e in (anonymous namespace)::ARMConstantIslands::doInitialConstPlacement(std::vector<llvm::MachineInstr*, std::allocator<llvm::MachineInstr*> >&) [clone .constprop.328] () from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_llvm-7c760c0d87163cbb.so
#5  0x00007ffff15c8908 in (anonymous namespace)::ARMConstantIslands::runOnMachineFunction(llvm::MachineFunction&) ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_llvm-7c760c0d87163cbb.so
#6  0x00007ffff1bb8ac5 in llvm::MachineFunctionPass::runOnFunction(llvm::Function&) ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_llvm-7c760c0d87163cbb.so
#7  0x00007ffff2458c13 in llvm::FPPassManager::runOnFunction(llvm::Function&) ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_llvm-7c760c0d87163cbb.so
#8  0x00007ffff2458cdc in llvm::FPPassManager::runOnModule(llvm::Module&) ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_llvm-7c760c0d87163cbb.so
#9  0x00007ffff245877d in llvm::legacy::PassManagerImpl::run(llvm::Module&) ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_llvm-7c760c0d87163cbb.so
#10 0x00007ffff0d69903 in LLVMRustWriteOutputFile ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_llvm-7c760c0d87163cbb.so
#11 0x00007ffff606d834 in rustc_trans::back::write::write_output_file::h713482cdaa178321 ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_trans-efa094249cef739c.so
#12 0x00007ffff606fd3f in rustc_trans::back::write::optimize_and_codegen::_$u7b$$u7b$closure$u7d$$u7d$::h1b757de20fba8b9a ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_trans-efa094249cef739c.so
#13 0x00007ffff6074c26 in rustc_trans::back::write::execute_work_item::hbc7cd39d8cd88c44 ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_trans-efa094249cef739c.so
#14 0x00007ffff607167a in rustc_trans::back::write::run_passes::h7cf08f2c47729966 ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/../lib/librustc_trans-efa094249cef739c.so
#15 0x00007ffff7b52353 in rustc_driver::driver::phase_5_run_llvm_passes::h7c9bbedc8969c4b3 ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-b65378ba5ffb99d4.so
#16 0x00007ffff7b18aa4 in rustc_driver::driver::compile_input::hf3e3aa4173908b86 ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-b65378ba5ffb99d4.so
#17 0x00007ffff7b646d6 in rustc_driver::run_compiler::h8f8d47f1d258a8a6 ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-b65378ba5ffb99d4.so
#18 0x00007ffff7a84115 in std::panicking::try::do_call::h206b9daee04f4ea2 ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-b65378ba5ffb99d4.so
#19 0x00007ffff77a8077 in __rust_maybe_catch_panic ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/libstd-9a66b6a343d52844.so
#20 0x00007ffff7aa0e62 in _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h5d196fbb3229f499 ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-b65378ba5ffb99d4.so
#21 0x00007ffff779d248 in std::sys::imp::thread::Thread::new::thread_start::h2c901daa88f3cb32 ()
   from /home/logic/build-tmp/rust-src/obj/arm-android/build/x86_64-unknown-linux-gnu/stage2/bin/../lib/libstd-9a66b6a343d52844.so
#22 0x00007fffeefda6ca in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#23 0x00007ffff74400af in clone () from /lib/x86_64-linux-gnu/libc.so.6

I will attempt to build llvm / rustc with debug info tomorrow to get some more information on what is going on.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Mar 3, 2017

Member

@TimNN FWIW timing out on travis may be fixed by re-running. If travis has a cold cache for both the docker image and LLVM it's likely to fail, but with sccache you'll likely cache LLVM the first time so the second build will have it cached (just a guess). If it passes locally though I'd be pretty confident that it'll pass on Travis.

Also thank you so much again for taking this on!

Member

alexcrichton commented Mar 3, 2017

@TimNN FWIW timing out on travis may be fixed by re-running. If travis has a cold cache for both the docker image and LLVM it's likely to fail, but with sccache you'll likely cache LLVM the first time so the second build will have it cached (just a guess). If it passes locally though I'd be pretty confident that it'll pass on Travis.

Also thank you so much again for taking this on!

@TimNN

This comment has been minimized.

Show comment
Hide comment
@TimNN

TimNN Mar 3, 2017

Contributor

I have (somewhat) minified the android assertion, compiling the generated llvm IR with llc triggers the same assertion. The assertion only triggers when compiling with optimizations. IR and the minified example: https://gist.github.com/52fcea6426c872869269114c47f96e1f

Contributor

TimNN commented Mar 3, 2017

I have (somewhat) minified the android assertion, compiling the generated llvm IR with llc triggers the same assertion. The assertion only triggers when compiling with optimizations. IR and the minified example: https://gist.github.com/52fcea6426c872869269114c47f96e1f

@TimNN

This comment has been minimized.

Show comment
Hide comment
Contributor

TimNN commented Mar 3, 2017

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Mar 3, 2017

Member

Nice! Want to submit that upstream?

Member

alexcrichton commented Mar 3, 2017

Nice! Want to submit that upstream?

@TimNN

This comment has been minimized.

Show comment
Hide comment
@TimNN

TimNN Mar 3, 2017

Contributor

Yeah, I'll just try to reproduce with an official llvm 4.0 build first.

Contributor

TimNN commented Mar 3, 2017

Yeah, I'll just try to reproduce with an official llvm 4.0 build first.

@TimNN

This comment has been minimized.

Show comment
Hide comment
Contributor

TimNN commented Mar 3, 2017

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Mar 4, 2017

Contributor

鈽旓笍 The latest upstream changes (presumably #40207) made this pull request unmergeable. Please resolve the merge conflicts.

Contributor

bors commented Mar 4, 2017

鈽旓笍 The latest upstream changes (presumably #40207) made this pull request unmergeable. Please resolve the merge conflicts.

@TimNN

This comment has been minimized.

Show comment
Hide comment
@TimNN

TimNN Mar 4, 2017

Contributor

I've been investigating the volatile emscripten failure a bit: It appears that the write_volatile (or the reading during verification) is miss optimized, see https://gist.github.com/TimNN/a43fc1376888e1d39ea5e9b93c099478 for the rust source, compilation options as well as optimized and unoptimized IR.

cc @kripken -- maybe you could take a look? The IR is sadly not freestanding (and depends on some rust libraries) but maybe you can see something anyway? I'm not sure how to debug this further -- if you have something I should try / do feel free to ping me here or on irc.

Contributor

TimNN commented Mar 4, 2017

I've been investigating the volatile emscripten failure a bit: It appears that the write_volatile (or the reading during verification) is miss optimized, see https://gist.github.com/TimNN/a43fc1376888e1d39ea5e9b93c099478 for the rust source, compilation options as well as optimized and unoptimized IR.

cc @kripken -- maybe you could take a look? The IR is sadly not freestanding (and depends on some rust libraries) but maybe you can see something anyway? I'm not sure how to debug this further -- if you have something I should try / do feel free to ping me here or on irc.

@kripken

This comment has been minimized.

Show comment
Hide comment
@kripken

kripken Mar 5, 2017

@TimNN: looks like the ExpandStructRegs pass is doing something wrong. It translates a bunch of insertvalues + a store volatile of their result into a bunch of store volatiles of undef. So it's losing the actual data, and only 0s will be stored.

That pass is originally from NaCl, and I'm not that familiar with its internals. So first thing that could help is to know if this is a new pattern of IR being generated? Is this a new test in 4.0, or is Rust in 4.0 generating something it didn't use to?

In particular, the relevant type here is %E = type { [32 x i64] }, that's what that pass is trying to legalize. Perhaps the pass can't handle arrays inside structs.

kripken commented Mar 5, 2017

@TimNN: looks like the ExpandStructRegs pass is doing something wrong. It translates a bunch of insertvalues + a store volatile of their result into a bunch of store volatiles of undef. So it's losing the actual data, and only 0s will be stored.

That pass is originally from NaCl, and I'm not that familiar with its internals. So first thing that could help is to know if this is a new pattern of IR being generated? Is this a new test in 4.0, or is Rust in 4.0 generating something it didn't use to?

In particular, the relevant type here is %E = type { [32 x i64] }, that's what that pass is trying to legalize. Perhaps the pass can't handle arrays inside structs.

@kripken

This comment has been minimized.

Show comment
Hide comment
@kripken

kripken Mar 5, 2017

Here's a before and after of the important part. The store volatile i64 undefs are what is wrong in the after.

kripken commented Mar 5, 2017

Here's a before and after of the important part. The store volatile i64 undefs are what is wrong in the after.

@TimNN

This comment has been minimized.

Show comment
Hide comment
@TimNN

TimNN Mar 5, 2017

Contributor

So first thing that could help is to know if this is a new pattern of IR being generated? Is this a new test in 4.0, or is Rust in 4.0 generating something it didn't use to?

The test is not new and the generated IR is exactly the same before and after the llvm upgrade. So it is my believe that something in LLVM / emscripten changed for 4.0 causing this failure (although I don't currently have a way to test that).

Contributor

TimNN commented Mar 5, 2017

So first thing that could help is to know if this is a new pattern of IR being generated? Is this a new test in 4.0, or is Rust in 4.0 generating something it didn't use to?

The test is not new and the generated IR is exactly the same before and after the llvm upgrade. So it is my believe that something in LLVM / emscripten changed for 4.0 causing this failure (although I don't currently have a way to test that).

@TimNN

This comment has been minimized.

Show comment
Hide comment
@TimNN

TimNN Mar 5, 2017

Contributor

Another note: Things work fine if the array is not wrapped in a struct, see https://gist.github.com/TimNN/419a598a0c5795dc2a83657ae684539f for source code and IR.

Contributor

TimNN commented Mar 5, 2017

Another note: Things work fine if the array is not wrapped in a struct, see https://gist.github.com/TimNN/419a598a0c5795dc2a83657ae684539f for source code and IR.

@kripken

This comment has been minimized.

Show comment
Hide comment
@kripken

kripken Mar 5, 2017

Ok, if it's the same IR as before, then either LLVM is optimizing it differently, or emscripten is compiling it differently. Running opt -O3 on the unoptimized ll from your gist results in the same output in both LLVM versions (well, minus a new nonnull attr). And running emscripten on that gives me the same results as well. However, when I opt -O3 your unoptimized code, I don't get the same optimized code - so perhaps the optimization flags matter. How are you generating the optimized code?

kripken commented Mar 5, 2017

Ok, if it's the same IR as before, then either LLVM is optimizing it differently, or emscripten is compiling it differently. Running opt -O3 on the unoptimized ll from your gist results in the same output in both LLVM versions (well, minus a new nonnull attr). And running emscripten on that gives me the same results as well. However, when I opt -O3 your unoptimized code, I don't get the same optimized code - so perhaps the optimization flags matter. How are you generating the optimized code?

@TimNN

This comment has been minimized.

Show comment
Hide comment
@TimNN

TimNN Mar 6, 2017

Contributor

Running opt -O3 on the unoptimized ll from your gist results in the same output in both LLVM versions

However, when I opt -O3 your unoptimized code, I don't get the same optimized code

I guess one of those should be optimized? (Which one?)

How are you generating the optimized code?

The optimized code is generated using opt -S -O1 vol.ll -o vol-opt.ll

Contributor

TimNN commented Mar 6, 2017

Running opt -O3 on the unoptimized ll from your gist results in the same output in both LLVM versions

However, when I opt -O3 your unoptimized code, I don't get the same optimized code

I guess one of those should be optimized? (Which one?)

How are you generating the optimized code?

The optimized code is generated using opt -S -O1 vol.ll -o vol-opt.ll

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Apr 23, 2017

Contributor

馃搶 Commit 516d3a0 has been approved by TimNN

Contributor

bors commented Apr 23, 2017

馃搶 Commit 516d3a0 has been approved by TimNN

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Apr 23, 2017

Contributor

馃挕 This pull request was already approved, no need to approve it again.

  • There's another pull request that is currently being tested, blocking this pull request: #41485
Contributor

bors commented Apr 23, 2017

馃挕 This pull request was already approved, no need to approve it again.

  • There's another pull request that is currently being tested, blocking this pull request: #41485
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Apr 23, 2017

Contributor

馃搶 Commit 516d3a0 has been approved by TimNN

Contributor

bors commented Apr 23, 2017

馃搶 Commit 516d3a0 has been approved by TimNN

@@ -265,4 +265,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");

This comment has been minimized.

@retep998

retep998 Apr 23, 2017

Member

Yay, static-nobundle is useful!

@retep998

retep998 Apr 23, 2017

Member

Yay, static-nobundle is useful!

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Apr 23, 2017

Contributor

鈱涳笍 Testing commit 516d3a0 with merge f857be8...

Contributor

bors commented Apr 23, 2017

鈱涳笍 Testing commit 516d3a0 with merge f857be8...

bors added a commit that referenced this pull request Apr 23, 2017

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.
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Apr 23, 2017

Contributor

馃挃 Test failed - status-appveyor

Contributor

bors commented Apr 23, 2017

馃挃 Test failed - status-appveyor

@TimNN

This comment has been minimized.

Show comment
Hide comment
@TimNN

TimNN Apr 24, 2017

Contributor

@bors retry

  • ar.exe failure
Contributor

TimNN commented Apr 24, 2017

@bors retry

  • ar.exe failure
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Apr 24, 2017

Contributor

鈱涳笍 Testing commit 516d3a0 with merge ad3f352...

Contributor

bors commented Apr 24, 2017

鈱涳笍 Testing commit 516d3a0 with merge ad3f352...

bors added a commit that referenced this pull request Apr 24, 2017

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.
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Apr 24, 2017

Contributor

馃挃 Test failed - status-appveyor

Contributor

bors commented Apr 24, 2017

馃挃 Test failed - status-appveyor

@TimNN

This comment has been minimized.

Show comment
Hide comment
@TimNN

TimNN Apr 24, 2017

Contributor

Yay, looks like all the builds timed out again, so things seem to be good to go. (I didn't verify all the logs this time).

Contributor

TimNN commented Apr 24, 2017

Yay, looks like all the builds timed out again, so things seem to be good to go. (I didn't verify all the logs this time).

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Apr 24, 2017

Member

@TimNN looks great to me!

I hope to branch beta later today, so want to pull out the fast-fail? I'll r+ this after the beta is branched.

I'd also like to reiterate that you're at least my own personal "Rust Hero of the last N Months" where N is two and counting. If we delay this for 3 more days then it'll be a 2+ month PR!

Member

alexcrichton commented Apr 24, 2017

@TimNN looks great to me!

I hope to branch beta later today, so want to pull out the fast-fail? I'll r+ this after the beta is branched.

I'd also like to reiterate that you're at least my own personal "Rust Hero of the last N Months" where N is two and counting. If we delay this for 3 more days then it'll be a 2+ month PR!

@TimNN

This comment has been minimized.

Show comment
Hide comment
@TimNN

TimNN Apr 24, 2017

Contributor

@alexcrichton: I removed the always fail commit.


I'd also like to reiterate that you're at least my own personal "Rust Hero of the last N Months" where N is two and counting. If we delay this for 3 more days then it'll be a 2+ month PR!

Thanks a lot! All the positive encouragement and feedback has helped a lot in keeping me motivated to work on the upgrade :).

Contributor

TimNN commented Apr 24, 2017

@alexcrichton: I removed the always fail commit.


I'd also like to reiterate that you're at least my own personal "Rust Hero of the last N Months" where N is two and counting. If we delay this for 3 more days then it'll be a 2+ month PR!

Thanks a lot! All the positive encouragement and feedback has helped a lot in keeping me motivated to work on the upgrade :).

@Kixunil

This comment has been minimized.

Show comment
Hide comment
@Kixunil

Kixunil Apr 24, 2017

I'd also like to reiterate that you're at least my own personal "Rust Hero of the last N Months"

Mine too! :)

Kixunil commented Apr 24, 2017

I'd also like to reiterate that you're at least my own personal "Rust Hero of the last N Months"

Mine too! :)

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Apr 24, 2017

Member

@bors: r+

Beta's branched, let's do this!

Member

alexcrichton commented Apr 24, 2017

@bors: r+

Beta's branched, let's do this!

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Apr 24, 2017

Contributor

馃搶 Commit 8994277 has been approved by alexcrichton

Contributor

bors commented Apr 24, 2017

馃搶 Commit 8994277 has been approved by alexcrichton

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Apr 24, 2017

Contributor

鈱涳笍 Testing commit 8994277 with merge 0777c75...

Contributor

bors commented Apr 24, 2017

鈱涳笍 Testing commit 8994277 with merge 0777c75...

bors added a commit that referenced this pull request Apr 24, 2017

Auto merge of #40123 - TimNN:llvm40, r=alexcrichton
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`
* [x] 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:**

Everything is green 馃帀
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Apr 25, 2017

Contributor

鈽锔 Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 0777c75 to master...

Contributor

bors commented Apr 25, 2017

鈽锔 Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 0777c75 to master...

@bors bors merged commit 8994277 into rust-lang:master Apr 25, 2017

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details

@brson brson added the relnotes label Apr 25, 2017

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Apr 25, 2017

Contributor

Thanks for slogging through this @TimNN.

Contributor

brson commented Apr 25, 2017

Thanks for slogging through this @TimNN.

@BatmanAoD

This comment has been minimized.

Show comment
Hide comment
@BatmanAoD

BatmanAoD Apr 25, 2017

Congratulations @TimNN!

Congratulations @TimNN!

@DemiMarie

This comment has been minimized.

Show comment
Hide comment
@DemiMarie

DemiMarie Apr 25, 2017

Contributor

Thank you @TimNN!

Contributor

DemiMarie commented Apr 25, 2017

Thank you @TimNN!

@TimNN TimNN deleted the TimNN:llvm40 branch Apr 25, 2017

@michaelwoerister

This comment has been minimized.

Show comment
Hide comment
@michaelwoerister

michaelwoerister Apr 25, 2017

Contributor

馃帀

Contributor

michaelwoerister commented Apr 25, 2017

馃帀

cnd added a commit to gentoo/gentoo-rust that referenced this pull request Apr 25, 2017

Merge pull request #254 from TyanNN/master
According to rust-lang/rust#40123 rust now supports LLVM 4
@pkphilip

This comment has been minimized.

Show comment
Hide comment
@pkphilip

pkphilip May 6, 2017

Wow! Thanks a lot @TimNN! That is some effort!

pkphilip commented May 6, 2017

Wow! Thanks a lot @TimNN! That is some effort!

@Kixunil

This comment has been minimized.

Show comment
Hide comment
@Kixunil

Kixunil May 6, 2017

I've just noticed that README mentions clang 3.x. Shouldn't this be updated?

Kixunil commented May 6, 2017

I've just noticed that README mentions clang 3.x. Shouldn't this be updated?

@rkruppe

This comment has been minimized.

Show comment
Hide comment
@rkruppe

rkruppe May 6, 2017

Contributor

@Kixunil That part of the readme is about the C and C++ compiler used for compiling C and C++ dependencies during the build, not about the LLVM version.

Contributor

rkruppe commented May 6, 2017

@Kixunil That part of the readme is about the C and C++ compiler used for compiling C and C++ dependencies during the build, not about the LLVM version.

@Kixunil

This comment has been minimized.

Show comment
Hide comment
@Kixunil

Kixunil May 6, 2017

@rkruppe I guess I'm too hungry and tired. Thank you for pointing that out! :)

Kixunil commented May 6, 2017

@rkruppe I guess I'm too hungry and tired. Thank you for pointing that out! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment