Upgrade LLVM

[nagisa]

Includes rust-lang/llvm#80

[rust-highfive]

r? @brson

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

[Mark-Simulacrum]

Travis seems to have failed on the newly introduced test. Perhaps it needs to be marked with the llvm greater than marker? https://travis-ci.org/rust-lang/rust/jobs/239126530#L1086

[nagisa]

Technically, it needs a marker for local-vs-system LLVM. I’ll think about it.

[eddyb]

@nagisa Don't we have something like that already? cc @alexcrichton

[nagisa]

@eddyb I can only see instances of min-llvm-version x.y which is not really correct to use in this instance.

[alexcrichton]

I don't believe we have one already, but it shouldn't be hard to add

[parched]

@nagisa Could you consider upgrading to 84c52ce which has my changes in too, to fix ARMv6-M

[nagisa]

This is ready, I think.

[sanxiyn]

@bors r+

[bors]

📌 Commit 7d251d8 has been approved by sanxiyn

[bors]

⌛ Testing commit 7d251d8 with merge 2c3b65c...

[bors]

💔 Test failed - status-travis

[Mark-Simulacrum]

Legitimate failure.

[00:57:45] /checkout/src/test/codegen/alloc-optimisation.rs:18:17: error: CHECK-NEXT: is not on the line after the previous match
[00:57:45] // CHECK-NEXT: ret void
[00:57:45] ^
[00:57:45] /checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen/alloc-optimisation.ll:1198:2: note: 'next' match was here
[00:57:45] ret void
[00:57:45] ^
[00:57:45] /checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen/alloc-optimisation.ll:1183:7: note: previous match ended here
[00:57:45] start:
[00:57:45] ^
[00:57:45] /checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen/alloc-optimisation.ll:1184:1: note: non-matching line after previous match is here
[00:57:45] %_7 = alloca %"collections::vec::Vec<u8>"
[00:57:45] ^
[00:57:45] /checkout/src/test/codegen/alloc-optimisation.rs:27:17: error: CHECK-NEXT: is not on the line after the previous match
[00:57:45] // CHECK-NEXT: ret void
[00:57:45] ^
[00:57:45] /checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen/alloc-optimisation.ll:1214:2: note: 'next' match was here
[00:57:45] ret void
[00:57:45] ^
[00:57:45] /checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen/alloc-optimisation.ll:1203:7: note: previous match ended here
[00:57:45] start:
[00:57:45] ^
[00:57:45] /checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen/alloc-optimisation.ll:1204:1: note: non-matching line after previous match is here
[00:57:45] %1 = call i8* @_ZN5alloc4heap15exchange_malloc17h749231974d061700E(i64 4, i64 4)
[00:57:45] ^
[00:57:45]
[00:57:45] ------------------------------------------
[00:57:45]
[00:57:45] thread '[codegen] codegen/alloc-optimisation.rs' panicked at 'explicit panic', /checkout/src/tools/compiletest/src/runtest.rs:2480
[00:57:45] note: Run with `RUST_BACKTRACE=1` for a backtrace.
[00:57:45]
[00:57:45]
[00:57:45] failures:
[00:57:45] [codegen] codegen/alloc-optimisation.rs

[nagisa]

@bors r=sanxiyn

[bors]

📌 Commit 3d15d79 has been approved by sanxiyn

[bors]

⌛ Testing commit 3d15d79 with merge f3c9977...

[bors]

💔 Test failed - status-travis

[nagisa]

@bors r-

never mind

[01:07:14] failures:
[01:07:14] [01:07:14] ---- bitvec::bitvec_iter_works_2 stdout ----
[01:07:14] thread 'bitvec::bitvec_iter_works_2' panicked at 'assertion failed: `(left == right)` (left: `[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235, 236, 237, 238, 239, 240, 241, 242, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252, 253, 254, 255, 256, 257, 258, 259, 260, 261, 262, 263, 264, 265, 266, 267, 268, 269, 270, 271, 272, 273, 274, 275, 276, 277, 278, 279, 280, 281, 282, 283, 284, 285, 286, 287, 288, 289, 290, 291, 292, 293, 294, 295, 296, 297, 298, 299, 300, 301, 302, 303, 304, 305, 306, 307, 308, 309, 310, 311, 312, 313, 314, 315, 316, 317, 318, 319]`, right: `[0, 127, 191, 255, 319]`)', /checkout/src/librustc_data_structures/bitvec.rs:277
[01:07:14] [01:07:14] ---- bitvec::bitvec_iter_works stdout ----
[01:07:14] thread 'bitvec::bitvec_iter_works' panicked at 'assertion failed: `(left == right)` (left: `[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127]`, right: `[1, 10, 19, 62, 63, 64, 65, 66, 99]`)', /checkout/src/librustc_data_structures/bitvec.rs:264
[01:07:14] note: Run with `RUST_BACKTRACE=1` for a backtrace.

are the real failures.

[nagisa]

I cannot reproduce the failures locally. The failure looks super weird to me though. I have a bunch ideas where the problem could be, but with homu being the only way to reproduce the issue it is super hard to try them out.

[nagisa]

Ok, the issue is exactly where I expected it to be – allocate_zeroed. Too bad that I cannot make it work no matter what I do (I’ve tried both making it a CallocLike and MallocLike), which suggests either some sort of UB in rustc_data_structures when mixed with memory optimisation or a bug in LLVM (unlikely, because calloc works just fine).

I’m not gonna investigate the exact cause of the bug; we can live without optimisation for allocate_zeroed IMO.

[nagisa]

@bors r=sanxiyn

[bors]

📌 Commit 7aaa22c has been approved by sanxiyn

[bors]

⌛ Testing commit 7aaa22c with merge f520e36...

[bors]

💔 Test failed - status-travis

[est31]

[00:45:38] error: verification with 'FileCheck' failed
[00:45:38] status: exit code: 1
[00:45:38] command: /checkout/obj/build/x86_64-unknown-linux-gnu/llvm/build/bin/FileCheck -input-file=/checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen/alloc-optimisation.ll /checkout/src/test/codegen/alloc-optimisation.rs

Seems legit

[nagisa]

@bors r=sanxiyn

[bors]

📌 Commit 406eddf has been approved by sanxiyn

[bors]

⌛ Testing commit 406eddf with merge 885d0f8...

[bors]

💔 Test failed - status-travis

[arielb1]

Timeout on i686?

@bors retry

[bors]

⌛ Testing commit 406eddf with merge ebbc9ea...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: sanxiyn
Pushing ebbc9ea to master...