Function returns weird structure on cross-compiling environment

#1

This code gives me a strange result on my cross-compiling environment. Are there any ways to correct it?
If this problem isn’t a Rust’s one but a my toolchain’s one, saying so would be great help for me.

The code returns like this on a x84-86 machine, which is what I expected:

new:   MyStruct { len: 0, v0: 0, n: 0 }
mynew: MyStruct { len: 0, v0: 0, n: 0 }

Conversely, it returns like this on a 32-bit PowerPC machine:

new:   MyStruct { len: 0, v0: 0, n: 0 }
mynew: MyStruct { len: 0, v0: 0, n: 1 }
thread '<main>' panicked at 'assertion failed: vv.n == 0', src/main.rs:28

I want both new and mynew to be the same.

Any idea?

#2

I found that the fix pasted below makes the code work fine on PowerPC:

struct MyStruct {
    len: usize,
    n: usize,   // swapped the order of this
    v0: u64,    // and this
}

Do I have to take care of alignment of structure members?

#3

Could be a bug. This is certainly not what the code should be doing. Can you start rustc with --emit llvm-ir on your PowerPC system? Also what version of rustc are you using (run rustc -V and pipe its output here)?

#4

Thank you for your reply, @llogiq .

I uploaded the result of the following command at here.

rustc --emit llvm-ir --target=powerpc-unknown-linux-gnu main.rs

My cross-compiler version is:

$ rustc -Vv

rustc 1.2.0-dev (fb7c0b44b 2015-05-19) (built 2015-05-26)
binary: rustc
commit-hash: fb7c0b44bb8dd47de07a05d6a17813dd614e3dff
commit-date: 2015-05-19
build-date: 2015-05-26
host: x86_64-unknown-linux-gnu
release: 1.2.0-dev

and I built it like this:

# rust
git clone https://github.com/rust-lang/rust.git
cd rust
./configure --target=powerpc-unknown-linux-gnu
make
make install

# cargo
git clone https://github.com/rust-lang/cargo
cd cargo
git submodule update --init
./.travis.install.deps.sh
./configure --local-rust-root=/usr/local \
make
make install

cd ~/.cargo
echo '[target.powerpc-unknown-linux-gnu]\n\
linker = "powerpc-linux-gnu-gcc"' > config
#5

It may or may not have something to do with your target definition – unfortunately I don’t have a PowerPC lying around to test this. Apart from the 32-bit usize and the target triplet, I see no change from the x86_64 version.