llvm::LLVMSetAlignment(load, align.bytes()asc_uint);

The load alignment is somewhat confusing.
I don't remember for sure, but I believe theLLVMSetAlignment function applies to theload instruction and not the location where the value is loaded.
Since your fix makes some test fails, I would tend to think that the code is correct as is, but I'm might be wrong.

In some code I compiled, the align argument (edit: in Builder::load) wasn't the same as the pointer's regular alignment, and gcc ended up dereferencing the wrong address.

Could you please share an example where this happens?

I'll try to make an example tomorrow.

ok I think I've got it now. Also, I have some code to reproduce the problem.

// repr(C) to prevent any field reordering.#[repr(C)]structX{// This causes the struct to require 8 byte alignment.a:u64,// This field is aligned to 8 bytes because the struct is aligned to 8 bytes, and it's at offset 8.// The type itself only requires 4 bytes, though.b:u32,c:u32,d:u32,}#[inline(never)]fnfoo(b1:u32,b2:u32){dbg!(b1);dbg!(b2);}#[inline(never)]fnbar(x:&X){// x.b loads the value from b with 8-byte alignment.// The load result also has 8-byte alignment, so when being passed to foo,// the second argument gets aligned to 8-bytes and is passed at argument offset 8// as if it were the third 4-byte argument.foo(x.b, x.b);}fnmain(){let x =X{a:1,b:2,c:3,d:4,};bar(&x);}

So I think maybe the alignment shouldn't be applied to the load result.

Can you explain what's the expected result with this code?

I get:

[src/main.rs:15:5] b1 = 2[src/main.rs:16:5] b2 = 2

which seems good.

I'm getting 2 on the first line and some random value on the second.

Which architecture are you on?

I was trying mips-unknown-linux-gnu.Since (edit: after) you asked, I also tried some other architectures including m68k but so far it hasn't happened anywhere except the mips one.

Also, it only happens with--release (I mean for cargo, e.g.y.sh cargo build --release). Without the--release, the argument gets passed fine.

Do you know if it would be easy to add a test for this fix?

I think a test for the behavior might not be perfectly reliable because the bug could accidentally be optimized out, but I'll try. I think maybe with a higher field alignment it'll happen on m68k, too.

Did you want to add a test or would you want to merge this as is?

I'd like to try to add a test that works on the architectures currently being tested in CI.

Ok, please tell me when it's ready!
Thanks a lot for your work!