Repository navigation
LLVM lint: Memory reference address is misaligned #28912
Description
This is a subissue of #7463.
pub enum H<A, B> {
L(A),
R(B),
}
pub fn test() -> H<i32, i64> {
H::L(0)
}Compile with rustc -C passes=lint and you get:
Undefined behavior: Memory reference address is misaligned
call void @llvm.memcpy.p0i8.p0i8.i64(i8* %2, i8* getelementptr inbounds ({ i8, i32, [8 x i8] }, { i8, i32, [8 x i8] }* @const3020, i32 0, i32 0), i64 16, i32 8, i1 false)
Manually setting alignment of const3020 to 8 in LLVM IR fixes the lint.
Activity
dotdash commentedon Oct 8, 2015
Seems to be caused by using the
sizing_typefor alignment.dotdash commentedon Oct 8, 2015
Oh, nevermind, I completely misread the problem here and confused it with a different issue. The alignment of the sizing type is fine and the right thing would indeed be to add the alignment info to the constant.
sanxiyn commentedon Oct 8, 2015
Eh, I am confused. Isn't the alignment of
{ i8, i32, [8 x i8] }4, i32 being the most aligned? Then why are we passing 8 as alignment to memcpy intrinsic? Is this related to sizing type?dotdash commentedon Oct 8, 2015
{ i8, i32, [8 x i8] }is just the specific representation for theLvariant. The typeH<i32, i64>is represented as%"H<i32, i64>" = type { i8, [7 x i8], [1 x i64] }, so its alignment is 8. And I think all our code deals with types rather than concrete variants when checking for alignment.We could probably extend that to allow for better packing of constants in some cases, but I'm not sure whether that's worth the trouble.
Auto merge of #28920 - dotdash:const_align, r=eddyb