powerpc64 nightly: discriminant value 0isize already exists

[cuviper]

Using powerpc64 nightly to rebuild itself gets many errors of "discriminant value 0isize already exists".

# rustc -Vv
rustc 1.16.0-nightly (df8debf6d 2017-01-25)
binary: rustc
commit-hash: df8debf6d9afc431adbbd8311dcaf2b70eb9762e
commit-date: 2017-01-25
host: powerpc64-unknown-linux-gnu
release: 1.16.0-nightly
LLVM version: 3.9

Using that exact git tree and ./configure --enable-local-rust && make:

[...]
Copying stage1 compiler (powerpc64-unknown-linux-gnu)
Building stage1 std artifacts (powerpc64-unknown-linux-gnu -> powerpc64-unknown-linux-gnu)
   Compiling build_helper v0.1.0 (file:///root/rust/src/build_helper)
   Compiling gcc v0.3.40
   Compiling libc v0.0.0 (file:///root/rust/src/rustc/libc_shim)
   Compiling unwind v0.0.0 (file:///root/rust/src/libunwind)
   Compiling core v0.0.0 (file:///root/rust/src/libcore)
   Compiling compiler_builtins v0.0.0 (file:///root/rust/src/libcompiler_builtins)
   Compiling alloc_jemalloc v0.0.0 (file:///root/rust/src/liballoc_jemalloc)
error[E0081]: discriminant value `0isize` already exists
    --> src/libcore/slice.rs:1178:5
     |
1176 |     Continue,
     |     -------- first use of `0isize`
1177 |     // Fold is complete and will return this value
1178 |     Done(T),
     |     ^^^^^^^ enum already has `0isize`

error[E0081]: discriminant value `0isize` already exists
  --> src/libcore/num/flt2dec/decoder.rs:46:5
   |
44 |     Nan,
   |     --- first use of `0isize`
45 |     /// Infinities, either positive or negative.
46 |     Infinite,
   |     ^^^^^^^^ enum already has `0isize`

[many more...]

error: aborting due to 57 previous errors

Build failed, waiting for other jobs to finish...
error: Could not compile `core`.

[nagisa]

Probably yet another case of i128 fallout. I can’t even begin guessing where the problem is given that the compiler did just fine compiling stage0. May be trans? This for example?

[cuviper]

I also see this with s390x, but the exact same configuration works fine on powerpc64le and x86_64, so that hints that this may be an endianness issue. I'm not sure how that would come up for enum discriminants though.

It also works fine on powerpc64 if I use the latest beta (rustc 1.15.0-beta.5 (10893a9a3 2017-01-19)) as the stage0 rustc, so it would seem to be a beta->nightly regression.

[cuviper]

@nagisa So that's:

llvm::LLVMConstIntOfArbitraryPrecision(t.to_ref(), 2, &u as *const u128 as *const u64)

Calling:

LLVMValueRef LLVMConstIntOfArbitraryPrecision(LLVMTypeRef IntTy,
                                              unsigned NumWords,
                                              const uint64_t Words[]);

That looks like a pretty good hunch, if LLVM is expecting little-endian Words[].

[nagisa]

@cuviper Could you try compiling the compiler with the C_big_integral swapped out for code below and see if it works (ugh the pain of not having big endian CI :/):

pub fn C_big_integral(t: Type, u: u128, sign_extend: bool) -> ValueRef {
    if ::std::mem::size_of::<u128>() == 16 {
        unsafe {
            let words = [u as u64, u.wrapping_shr(64) as u64];
            llvm::LLVMConstIntOfArbitraryPrecision(t.to_ref(), 2, words.as_ptr())
        }
    } else {
        // SNAP: remove after snapshot
        C_integral(t, u as u64, sign_extend)
    }
}

---

Also if you hop onto IRC, we could organise a “low” latency debugging session :)

[cuviper]

On IRC, @nagisa suggested running this test command with the patch above:

python x.py test src/test/run-pass --stage=2 --test-args i128

Now, the patch doesn't directly help me when bootstrapping with the nightly stage0, because that cross-compiled rustc still has the bug. But I can run that test after bootstrapping with the beta stage0, where the build had looked like it succeeded, and indeed run-pass/i128.rs fails:

thread 'main' panicked at 'assertion failed: `(left == right)` (left: `0`, right: `2338558778202779088322560000000000`)'

on this part in particular:

    let z: i128 = 0xABCD_EF;
    assert_eq!(z * z, 0x734C_C2F2_A521);

And that makes sense -- if z gets built with its 64-bit halves swapped, then the lower half will be 0 and squaring will overflow all the significant bits resulting in 0 overall. That right in hex also shows it has a reversed value, 0x734c_c2f2_a521_0000_0000_0000_0000.

With the patched C_big_integral, the same test now succeeds, huzzah!

(run-pass/i128-ffi.rs fails to link in both cases, because rust_test_helpers.c only defines the necessary functions for defined(__amd64__).)

[cuviper]

Now, whether that fix will correct the issue with enum discriminants is harder to tell. The run-pass enum tests are passing for me after beta bootstrap with or without the patch. I think the cross-compiled aspect is probably important to the original problem, so I won't know until I can try with a new nightly stage0.

[cuviper]

Success! Using:

$ rustc -Vv
rustc 1.16.0-nightly (24055d0f2 2017-01-31)
binary: rustc
commit-hash: 24055d0f2aa8dce5caed7544e6006aa48dceaea5
commit-date: 2017-01-31
host: powerpc64-unknown-linux-gnu
release: 1.16.0-nightly
LLVM version: 3.9

The native rebuild now completes successfully, and also passes the i128 tests. Thanks!