Code change:
Trying to natively build powerpc64 as of , I get an ICE in stage 1:
FWIW beta () builds fine. I'll see if I can bisect it.
I seem to be hitting unrelated issues when bisecting, so it may be regressing in and out lately... It still ICEs on powerpc64 as of . I found that powerpc64le builds fine though, so this could be a general big-endian issue. If I get time I'll try s390x. Also, the reported region sometimes changes, though still the same location. Most often I get: error: internal compiler error: Region parameter out of range when substituting in region 'b (root type=Some((&&'b str,))) (index=1) But a few times I've seen: error: internal compiler error: Region parameter out of range when substituting in region 'a (root type=Some((str::pattern::StrSearcher<'a, 'b,))) (index=0) And the backtraces are still useless...
Could you post the results of ?
That's doing a rebuild from the working dir of my prior attempts, so the only interesting piece is the stage1 libcore that ICEs. If you want the log of a complete build from scratch, I can get that too.
I'm seeing a different error: Could you compile with debuginfo to get a backtrace? That's the setting in
Fresh build directory, debuginfo enabled: error: internal compiler error: Type parameter (T/0) out of range when substituting (root type=Some((&mut [T], _))) substs=[] Same dir just building again: error: internal compiler error: Region parameter out of range when substituting in region 'a (root type=Some((str::pattern::StrSearcher<'a, 'b,))) (index=0)
Very odd. rustc compiled on x86-64 (both a rustc I hand-compiled and the official nightlies) works without any problems, but rustc compiled on powerpc64 crashes with all sorts of random errors. I wonder whether there is some sort of LLVM bug - the next beta uses LLVM 4.0.1, so I should check whether that fixes things. Also, there shouldn't be any LLVM IR differences between a rustc compiled on powerpc and a rustc compiled on x86, so maybe I could do a diff
We've seen weird differences between cross- and native-compiled rustc before for big-endian machines, which seems confirmed by powerpc64le working fine here. I'm still trying to get s390x access... cc who has found a few of these.
The usual problem is that cross-compiled and native-compiled metadata end up being incompatible, so an x86-built ppc64 libcore is incompatible with a ppc-built ppc64 libcore. Through maybe we've ended up in a case where ppc can't decode its own metadata.
Yes, my first suspect would be endianness issue. It could be fairly plausible that the metadata decoder is correct, but the encoder is not, hence the bug showing up on ppc-built stuff only.
I got an s390x build, and it fared even worse. Tons of move errors on types like this: before it finally ICEd: thread 'rustc' panicked at 'assertion failed: (Qualif::MUTABLEINTERIOR)', I'm guessing that these particular errors and ICEs are not significant in themselves, only as signs of some more general corruption.
Oddly enough, if I use an x86 stage0 to compile a powerpc stage1, or an powerpc stage0 to compile an x86 stage1, everything works fine, but if I use a powerpc stage0 to compile a powerpc stage1, the powerpc stage1 created is broken.
I can't figure out a good way to debug this without a powerpc computer. So I'm gotta leave this alone unless anyone's going to help me track it down (e.g., ssh access to a fast(!) powerpc computer).
I don't know if I can provide any machine access -- I'll check -- but I will keep working on this myself. Any tips for how to approach this? I tried valgrind, but I got so many errors that I think either I'm using it wrong or that build is just hopelessly broken.
Bisecting took me to 's merge commit . The parent commit builds fine. I didn't drill down into the individual commits for that PR, as it just seems to be iterating different ideas. If you look on master, also moved that code to to use in more places. I don't know what that code would have to do with endianness or cross-compiling weirdness per se, but I do worry about the memory alignment of these: Later the temp block gets cast to , as do the input pointers in the first place, which would seem to imply that alignment won't matter. But if is still having an effect as stated, then I worry that perhaps the extra alignment constraints are just being assumed in the code generated to move between , , and . The input could have a smaller alignment than .
I replaced with a naive byte-byte swap on master, and it works! Now to figure out the right fix...
Just removing that gets a working build! Regarding endianness and cross-compiling, could there be a bug in the way the simd type is translated to LLVM? Especially since it's being seen through a pointer. I'm going to do some comparisons of the builds with and without that . if it would help, I could share those builds somewhere for you to grab.
cc since I'm blaming your PRs...
Affects both powerpc64le and powerpc64 in Debian now: Correction, the latest upload for ppc64 builds fine:
The Debian bug is little-endian not big-endian. This bug is the other way around, and is very old.
Right, the failure on big-endian was a different one for the previous 1.30 upload to experimental.
Er for the record, no the previous beta-7 was also problematic for little-endian but OK for big-endian - the big-endian one , otherwise it would be fine (20 test failures). Anyway we have some clues on the other bug, more comments there.
Isn't this bug fixed by ? - i.e., what is the Rust situation on powerpc?
This is likely fixed. Rust 1.32.0 succeeded on ppc64el, see
This bug is on big-endian, the link you pasted is little-endian, but if you remove the "el" at the end of the URL you get to the big-endian results which are also OK. We do things slightly differently from Fedora though.
do you know what the status on Fedora is?
It was "fixed" by by disabling SIMD in that function -- not really a satisfactory solution IMO. So in that sense, we don't have any issue on Fedora any more. But perhaps we should see what happens to codegen these days if we revert that and try allowing SIMD there again. edit: to be clear -- I will try changing that back myself to see what happens.

Related discussion:
text: // #[repr(simd)], even if we don't actually use this struct directly. // // FIXME repr(simd) broken on emscripten and redox <del> // It's also broken on big-endian powerpc64 and s390x.  #42778 #[cfg_attr(not(any(target_os = "emscripten", target_os = "redox", target_endian = "big")), repr(simd))] </del> <ins> #[cfg_attr(not(any(target_os = "emscripten", target_os = "redox")), repr(simd))] </ins> struct Block(u64, u64, u64, u64); struct UnalignedBlock(u64, u64, u64, u64);